Azure Logic Apps – EPS Team

AS2 agreement - MDN Issue in Azure Logic Apps

EPSLAB Team — Thu, 16 Mar 2017 20:05:57 GMT

While doing testing with integration partner for AS2 implementation using Logic Apps, if you are clueless when partner mentions that MDNs are not getting processed in their system despite having all the correct settings, then this post might be of some help to you.

We faced this issue when we tested following scenario with one of our integration partners. Following was the scenario:

The AS2 agreement was configured for sending Signed and Encrypted MDN messages in our system.

We recently migrated this AS2 agreement from BizTalk server and this configuration was exactly same as it used to work with BizTalk server.

After two days of long testing and debugging hours with partner and trying out different permutations and combinations to isolate the issue, we got this working only when we added some text in MDN Text box in Agreement Receive settings as highlighted below:

Logic App Resubmission

EPSLAB Team — Sat, 18 Feb 2017 17:09:27 GMT

While handling enterprise scale workflows / B2B Integrations, failure points should be handled by design. Azure Logic Apps provide great platform to stitch such integrations/processes that span across multiple actions on a trigger message. Comparing Logic apps to BizTalk orchestrations, there are lot of differences between how workflow execution is handled. Hence design should take care how message failures can be handled gracefully. In a typical B2B integration scenario using EDI messaging, most of the integration processes involve following steps:

Handshake with B2B partner in a secured manner (usually using AS2 over Http transport protocol)
EDI message validation
Message transformation
Sending message to Line of Business application of an enterprise

And then it also involves other complexities like batching/de-batching, process tracking and failure recovery. In BizTalk message persistence and orchestration state persistence helped resuming the failed instances from the stage it failed. And in some scenario compensation block with scope shape helped handling of workflow failures. Azure logic app has provided a feature called Resubmit. This can retrigger the new run with same trigger inputs with which the original run instance was invoked. But to use this to handle failures and enabling resume from the stage it failed, the total workflow should be designed by breaking whole workflow process into logical atomic stages and creating one Logic App each for each logical stage. This should ensure message integrity and consistent state at each logical stage. Hence if failure happens in a particular stage due to the reasons other than data issues where message resume can solve the problem, then Resubmission feature can be safely used at each logical stage to resume the process.

Hello world!

EPSLAB Team — Sun, 04 Dec 2016 20:30:42 GMT

Welcome to Developer Network. This is your first post. Edit or delete it, then start blogging!