Avaya Support Forums  

Go Back   Avaya Support Forums > Avaya Breeze™ Collaboratory

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 07-01-2016, 05:27 AM
ander548 ander548 is offline
Whiz
 
Join Date: Jun 2016
Posts: 37
ander548 has 10 reputation points
Default EventingConnector Snap-In through HTTP

I am using Avaya Collaboratory and have setup in the Event Catalog an event that expects a JSON REST post and used that event to start a workflow I created in Engagement Designer. I can test this workflow by simulating the event by creating an instance and it works great. What I can't figure out how to do is to trigger this event from the outside world. After much digging, I found the link below that mentions in the "Publishing Events through HTTP" that there is a base URL you can call with the format: https://securityModuleIP/services/ EventingConnector/events

I cannot seem to figure out where this Security Module IP comes from, so can anyone help with that? I would need this IP to be externally accessibly so that it can be called from anywhere, which seems to be the point of this function. The only external IP address I see in my Collaboratory documentation is the Outgoing NAT IP/FQDN, but if I plug that in to the URL above I get a 404 error.

https://www.devconnectprogram.com/me...e-summary.html
Reply With Quote
  #2  
Old 07-01-2016, 10:18 AM
mmontgom mmontgom is offline
Whiz
.
 
Join Date: Mar 2012
Posts: 45
mmontgom has 11 reputation points
Default EventingConnector Snap-In through HTTP

Ander458,

You should be using the EDPa security ip addess assign to your lab.
Reply With Quote
  #3  
Old 07-01-2016, 10:31 AM
vjheath vjheath is offline
Hot Shot
.
 
Join Date: Feb 2015
Posts: 12
vjheath has 10 reputation points
Default Triggering ED workflow through postman

Now that you have your start schema in the Event Catalog, you can use POSTman to trigger that Engagement Designer workflow externally with these steps:

1. Download Postman from Google Store.
2. Using “0XX” is your collaboratory lab ID, Populate with:
3. POST - https://edpa0XX.collaboratory.avaya....nnector/events
4. Using the default “form-data” body type, populate the family, type, version and eventBody parts. Use something like this for the eventBody:
{"Team":"test", "MeetingName":"Operational Outage"}
This matches this schema from the event catalog:
{"title":"FormTeam","type":"object","properties":{ "Team":{"type":"string"},"MeetingName":{"type":"st ring"}}}
5. Click SEND to trigger an instance of your workflow.

I hope this helps!
-Valerie
Reply With Quote
  #4  
Old 07-02-2016, 05:36 AM
ander548 ander548 is offline
Whiz
 
Join Date: Jun 2016
Posts: 37
ander548 has 10 reputation points
Default

Thanks Valerie! That seems to work great, but what if the HTTP POST I want to use comes from a 3rd party service and I can't modify it to include family, type and version? Can I just accept a straight POST with the parameters it currently uses? For instance, I do a POST to some service that triggers a POST back to the URL I provide (the edpa0XX URL you gave me) and then have an event triggered when that POST comes back. Is there anyway to do that because many times the format of the POST isn't under the control of the developer using ED. thanks!
Reply With Quote
  #5  
Old 07-02-2016, 05:49 AM
ander548 ander548 is offline
Whiz
 
Join Date: Jun 2016
Posts: 37
ander548 has 10 reputation points
Default

A much more versatile way to do this would be to give each event in the Event Catalog a unique ID, and then just append that to the end of the URL so it just knows what the event is without having to somehow modify the incoming POSTs format. ie-My event would have an ID of 123 and I would simply use the URL: https://edpa0XX.collaboratory.avaya....tor/events/123 and not have to modify the incoming POST at all.
Reply With Quote
  #6  
Old 07-20-2016, 03:08 PM
joele joele is offline
Member
.
 
Join Date: Jul 2016
Posts: 7
joele has 10 reputation points
Default

Hi Andrew, sorry it's taken me so long to reply to this thread. Your suggestion is a very interesting one! We'll definitely have to consider it in a future release.

In the meantime, it's not impossible to interface to a system that is not flexible in the format of the events that it publishes. This is where the concept of a "Connector" snap-in comes into play. The Connector would:
- Expose a web service that can take the incoming event in whatever form the publisher wants to send it.
- Massage the data into a form that can be accepted by the Breeze Eventing Framework and Engagement Designer.
- Invoke the Java Eventing Framework interface to publish the event locally without needing to send another HTTP request.

Does that make sense? Note that this approach could also be used for event retrieval via (long) polling and in the future, websockets.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 01:14 AM.

This Forum is provided solely for the use and convenience of Avaya customers and partners. Use of the Forum is subject to the Terms and Use and Privacy Statement found at www.avaya.com. No other use is permitted. The Forum including all content posted is “AS IS” and Avaya expressly disclaims all warranties and/or guarantees as to its accuracy, reliability, usefulness, quality or non-infringement of intellectual property. Avaya reserves the right to remove any content posted on the Forum at any time and for whatever reason.

Avaya will not be liable for any content posted on this Forum, including, without limitation, any errors or omissions or for any losses or damages of any kind incurred as a result of use or reliance on any content, regardless of its origin.

You expressly understand and agree that you assume all risks associated with use or reliance on this content.