It's about using one API's reply channel in another API.
I have API 1 which does some operations on the entity and unlocks the entity.
& API 2 which unlocks an entity. I have make them work so that they can be called independently.
API2 unlocks the entity using http inbound and outbound gateway.
I am calling API2's http inbound gateway request-channel in API1 to call API2(to implement unlock part of API1) and if API2 returns success, I want to send custom success response from API1 so for that purpose, I am using API2's reply channel as a input channel in API1 which is messing things up.
so If I call API2 independently, at the end it also calls API1 chain flow where API2's reply channel is used as input channel(which is obvious) and throwing exception Expression evaluation failed as I am using some variable from the chain above.
Is there any way to handle it in a better way? Please help!
Doesn't look like your design is OK. Since you have some common API to be called from API1 and API2, then just extract it into that separate internal API. For that purpose you indeed can use some input channel for a service activator call.
Your API1 and API2 must not use any reply channel, but reply on just replyChannel header populated by the request-reply pattern implementation in the inbound gateway. You are making a mess exactly with that reply-channel on those inbound gateways.
We don't know what is your configuration, so cannot give you more precise advice. But one more time: the inbound gateway populates a replyChannel header and the last endpoint in the downstream flow simply can reply on this header to produce a reply into a proper place.
I think we already had with your similar discussion over here: calling http rest API from another API.
Either way, please, learn what is replyChannel header and try to avoid using those reply-channel configurations, especially if you are going to reuse downstream sub-flow from different places: https://docs.spring.io/spring-integration/docs/current/reference/html/messaging-endpoints.html#gateway
Related
Is there any guidelines/recommendations for the webhook URL that I can use for setting up the event notifications?
I am thinking of using something like this - /webhook/v1/{uniqueAppID}. The uniqueAppID changes for every envelope, I dynamically construct the URL and set it to the EventNotification object while creating the envelope.
The unique app id is used to track the response from DocuSign, So if at all there is any issue in parsing the response, I would know for which envelope/app id I have got the notification.
I read that the system will retry delivery for failures only after a successful acknowledgement is received from the webhook, In my case, it will be like having multiple webhooks. Will this setup cause any issues in retrying the failures? Does setting up the url like /webhook/v1?uniqueAppID={uniqueAppID} helps?
Thank You
Great questions.
First up, you don't have to use any kind of endpoint/URL schemes. You could have them all go one place. The information that you get from DocuSign in the payload would allow you to know everything you need about the envelope and if you need additional information - you could make API calls to determine this.
However, I would agree that if you need this information, using different endpoints would give you greater flexibility. Also, if it's different apps, you could, in theory, deploy them separately and thus the endpoint code would change without affecting other apps.
As for retry, this is done in case DocuSign does not get a 200, 201 or other HTTP response that's positive from your web server. If DocuSign gets 401 or 500 etc. If no response is received, DocuSign would retry again in 24 hours.
That should not impact your decision about the design.
One last thing to consider, you cannot be behind firewall/VPN etc. Highly recommend you consider a public cloud provider (Azure, AWS, Google) for your app to avoid networking issues.
When using envelope-level webhooks, the triggers and destination URI are embedded into that envelope. After the envelope enters a predefined state like 'sent' or 'completed', the writeback targets the URI that you provided. Unless you intentionally change this, it should remain envelope-specific.
This is different from our typical Connect setup, which would have a single URI per listener and envelopes writebacks would be directed to the listener URI at the time they're processed.
Any subsequent failure or retry attempts would follow the standard guidelines outlined here: How to get docusign webhook to retry on failure?
I am converting a monolithic application to microservices. I have set up an API Management layer and a Service Bus all within a Service Fabric. The idea is to use messages to communicate to the microservices so they do not know about eachother.
When one microservice needs information it posts a message to the service bus and it gets fulfilled and a reply is sent and correlated.
The only problem is that the API Management posts the message to the service bus and returns without waiting for a reply therefore the client does not get a response.
Is there a way to have the API Management wait for a reply?
Would this need a sort of broker service in-between?
Is it better to just have a REST layer on each microservice that the API Management could call but then the services would use the service bus?
Thanks for any help.
UPDATE:
I think the only way to have Api Management wait is use of a logic app. Not sure about this.
Any Azure experts out there?
The way APIM is behaving is actually expected.
Service Bus is meant to decouple different (micro)services and inherently doesn't have a request-response style of operation though it can be implemented that way.
Here is one way to can design/implement you system
First, for a request-response style operation with Service Bus, one way you can achieve it is by using two queues.
One for sending the request (along with some Unique ID - GUID will do) and the other for receiving the response (which again contains the Unique ID sent in the request).
Instead of having APIM work with Service Bus, call a Logic App or Function which does this for you.
Finally, waiting for the response is something that will depend on your use case.
If you have a very long running task, its best to follow the Async Pattern implemented by both Logic Apps and Functions (using Durable Functions), which return a 202 Accepted response immediately with a status URI that your client can poll for updates.
But if its a quick response (before the HTTP request times out), you could probably wait for the response service bus message and return the response then. For this, your Logic App or Function would have to poll/wait for the service bus message with the same unique ID and then return the response.
I have an Azure Event Grid topic:
https://xxx.westeurope-1.eventgrid.azure.net/api/events
Is there any way to direct clients to publish events to https://xxx.mydomain.com/api/events without getting certificate validation errors, etc.?
It would appear, after researching further documentation and speaking to Microsoft that this is currently not possible. If you create a CNAME entry in your own DNS to point to the Azure fqdn of the endpoint, certificate errors are (understandably) generated.
You could use some type of API gateway to accomplish this. The gateway would have your desired domain name and route for the public to submit requests. A service
behind the gateway would forward the request to the event topic's endpoint.
Another option, but based on the same idea mentioned above, would be to use Azure Functions. The function becomes the gateway and the client publishes to the function's endpoint. Code within the Azure Function bundles the request and forwards it to the event topic.
I'm currently using the Functions approach. My function accepts a generic JSON body, validates a few things, packages it up so it has everything the event topic needs (access keys, headers, correct properties for the event schema, etc), and sends it off to the event topic endpoint. If everything works, I send the client a 200 HTTP status from the Azure Function. If there's a problem, I send a 400 or 500 series status as appropriate.
I wanna build a small workflow using Azure Logic Apps that contains an "Approval" step, which is simply an API call in my own system, similar to office 365 approval connector.
However, from what I found on the internet, the only way to make a long running task in Azure Logic Apps is to use Webhooks.
In Webhooks, I could not set a value to the parameter I created "Bool-Approved".. so, How can I check it later in a condition step?
The other possible solution maybe is to use Swagger to have an "Bool-Approved" parameter. However, it does not support long running action!
What's the possible solution for me?
As you mentioned, the way to do it is to use the Webhook action, and for that you need to implement the Subscribe/Unsubscribe pattern described here. The webhook action will allow you to get any payload (via an HTTP Post) from the instance-based webhook you are subscribing to.
The points below are a summary of this blog post:
https://www.mexia.com.au/correlation-identifier-pattern-on-logic-apps/
To implement the Subscribe/Unsubscribe Webhook pattern you need to consider:
Subscription store: A database to store the unique message Id and the
instance-based callback URL provided by the webhook action.
Subscribe and Start Request Processing API: this is a RESTful API that is in charge of starting the processing of the request and storing the
subscription.
Unsubscribe and Stop Request Processing API: this is another RESTful API that is only going to be called if the webhook action on the main workflow times out. This API is in charge of stopping the processing and deleting the subscription from the store.
Instance-based webhook: this webhook is to be triggered by your own custom approval event. Once triggered, your webhook is in charge of getting the instance-based callback URL from the store and invoking it. After making the call back to the main workflow instance, the subscription is to be deleted. This is the webhook that is in charge of sending the payload you require to the waiting webhook action in your Logic App.
The subsequent actions will be able to use that response body, so you can implement your conditions, etc.
You can follow the blog post mentioned above to see a detailed example and get more details on how to implement it.
make you api return HTTP code 200 if the response if "ok" and 400 if the response is "not ok". This way you can force logic app to behave the way you need it to behave..
DocuSign Connect Guide states that when creating a listener, for the method name DocuSignConnectUpdate, you need one parameter type DocuSignEnvelopeInformation.
Only problem is on their DocuSign.eSign namespace, there is no DocuSignEnvelopeInformation class to be found.
Is the guide out of date or am I missing something?
The part of the Connect Guide you're quoting only applies if you configure your webhook (Connect) subscription to use SOAP message transmission format. (Which I advise against.)
If you choose to use SOAP message transmission format, your listener needs to be a SOAP server that will process incoming SOAP requests to method DocuSignConnectUpdate with parameter DocuSignEnvelopeInformation
In this case, your app is receiving the SOAP requests, not requesting them, as is more usual when using SOAP. Because your listener is receiving the SOAP requests to DocuSignConnectUpdate, it does not appear in the DocuSign Signature SOAP WSDL file that you reference. That WSDL file and name space describe the methods that your app requests.
Rather than setting up a SOAP listener, it is usually easier to set up a plain HTTPS listener (server) to receive and process the incoming webhook messages.