The HTTP Proxy feature is not used very often, but when it is used it’s generally very important.
I understand where the feature came from originally, however, I often get use-cases that are slightly different. They all share the same feature however, they need a realtime response.
Two examples I had:
Somebody needed a non-realtime feed for their Channable connection (not that large, maybe 50-100kb). I created a process that stores every product every 24-hours and then on-demand merges that storage into a single XML and returns that to the requester.
I’m currently working with a system that requires ‘acceptance’ of an order. The ‘acceptance’ message is not static, but needs to contain the items sent. The ‘acceptance’ needs to be the real-time response to the request.
Both of these use-cases are made very difficult because Alumio requires the HTTP-proxy to do a call. This almost forces me to use httpbin.org - which is something I’d reaaaally like to avoid.
Would a setting on the HTTP-proxy that just says “No outgoing call” be possible?
I can imagine that would be a great addition for your use-cases. Furthermore, posting sensitive data to public web services like httpbin.org would not be a preferable way. Therefore, I would pass your request regarding “No outgoing call” on to the team for further discussion of the possibility.
As for a workaround, for example #1, I would use the Alumio’s storage API endpoint, which is GET /storage/entities/{identifier} to fetch the entities of the storage as the destination URL. Then fetch the contents and merge them as the HTTP proxy’s response.
Regarding example #2, I would create an entity transformer to handle the order “acceptance”. Then, I would use an existing Alumio’s API endpoint, such as the POST /transformers/execute as the destination URL to execute the created entity transformer.
The workarounds might not be so practical, but they would be a good idea to avoid calling HTTPBin.org or other public web services.
Thanks for the advice! I never considered calling the transformers with the separate call, but that would indeed fix the issue - because it’s basicly the same as executing the transformer within the HTTP proxy, it can simply be a middle step.
For most many use-cases that would atleast make it possible to build it in Alumio, though the ‘no outgoing call’ option (like the outgoing ‘no action publisher’) would still be preferable.
We discussed the possibility of the “no outgoing call” and we don’t think that we will implement it in the future. We have an HTTP client plugin called “Mock requests” that would mock the request and returned the response defined in the plugin instead of actually calling the destination endpoint.
Another thing is, we have another issue, which the “Transformer response data” response processor can only access the origin request’s query (GET) parameters. We will have to research further about the possibilities to overcome this issue.
The ‘mock requests’ feature is a pretty good alternative to calling the transformer directly - keeping transparancy/logging while being only a minimal inconvenience.
I’ve not really used the ‘mock requests’ feature, so I don’t know: can you use JMESPath queries in the ‘mock requests’ body? Otherwise, you still can’t send (and receive back) dynamic data.
Unfortunately, the Mock request plugin doesn’t support placeholders yet. Therefore, we don’t think it can help you in this specific case.
As I mentioned in my previous reply, the feasible solution would be setting the destination endpoint to one of the Alumio API endpoints that is related to your flow. For example, getting a content of an Alumio storage or executing an entity transformer.