I want to launch my Snap-In with a web services call from an external application. I created a Postman POST for my event and it works fine. The application I am using allows me to specify URL and request body. I use the EventingConnector/events entry point and I see the web services call using traceHTTP. However, I cannot figure out how to encode the RequestBody of the POST.

I know I need the following:

family
type
version
eventBody

If the application only allows me to enter a string for the RequestBody, how would I format that? I've tried several different combinations, but although I see the call, it never launches my Snap-In.

Thanks!

Hi Andrew,

I would have expected that it would be easy in Postman to see what was actually sent over the wire to the invoked service, but it was surprisingly difficult. I followed the instructions here to view the request being sent: http://stackoverflow.com/questions/33793629/postman-how-to-see-request-with-headers-and-body-data-with-variables-substitut

Below is what I saw for one of my requests. One thing that you'll note is that you need to at least be able to set the content type to multipart/form-data and specify a separator. Will you be able to do that in your application? We've considered adding another HTTP endpoint that would have a JSON-based envelope for the metadata instead of using form data but haven't yet gotten that slated into a release.



Request Headers

Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Content-Length:573
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryBOR4ZUSbNHj5QBkU
Host:135.169.20.25
Origin:chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Postman-Token:947b1934-37bc-ecfd-4b81-bb360549f8d1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36


Request Payload

------WebKitFormBoundaryuApnm4l9swNZ4NOA
Content-Disposition: form-data; name="family"

LowInventory
------WebKitFormBoundaryuApnm4l9swNZ4NOA
Content-Disposition: form-data; name="type"

LowInventoryAlert
------WebKitFormBoundaryuApnm4l9swNZ4NOA
Content-Disposition: form-data; name="version"

1
------WebKitFormBoundaryuApnm4l9swNZ4NOA
Content-Disposition: form-data; name="eventBody"

{"Description":"Widgets", "Manufacturer":"Widgets, Inc.", "PartNumber":"123456789", "InventoryCount":"5","CountAsString":"5"}
------WebKitFormBoundaryuApnm4l9swNZ4NOA--

I actually saw that, but could not figure out how to encode it as a single string. I spoke to the developers of the web application and they essentially told me, "There are a ton of ways to encode a POST and Postman does it the hard way. Ask the people responsible for your system (that would be Avaya) to tell you exactly what they want to see without all the Postman complexity."

So, my question is this. Do I have to do what Postman does or is there an alternative encoding that Breeze will accept?

There's really not Postman peculiarities at play here. The thing that is somewhat non-traditional is that we chose multi-part form data as the means to encode events being published to Breeze. We did this because we wanted keep the Eventing Framework Connector agnostic as to the encoding of the actual event body, and multi-part seemed like the best way to achieve that agnosticity (to make up a word).

If I were to do it over again, I think I probably would have gone with a much simpler JSON schema, with a potential consequence of that being that we would sacrifice the ability to handle other encoding types. This would doubly be true given that ED has been designed to be very JSON oriented. I'll go refresh the request internally to add this feature (simplified encoding for HTTP events) in a future release.

In the meantime, what problem are you having with encoding multi-part as a single string? Is it the quotes that are embedded? I would think that the developers of your application should be able to tell you how to escape quotes, line feeds, etc so that they can be included in a single string.

Thanks, Joel. I've taken your response back to the web developer and it appears that until one side writes code to accommodate the other, I'm out of luck. :-(

Sorry to hear that, Andrew. I've raised this issue internally and we'll see what we can do to address it. It might be a long shot for our next release.

I appreciate that. I've raised the same issue with the web team and will let you know if they chose to budge. I see both sides of the argument.

As do I!

Hi Andrew: one additional thought on this. Another option that is available to you is to create a simple Connector snap-in that would:
- Expose a web service that receives events in whatever format you choose
- Publish this event to the Eventing Framework using the Java interface.

This is essentially what our Eventing Framework Connector does.

Happy Holidays!