I’m aware that this is a debatable feature and some organizations do not allow it. My opinion is that it could be tolerated under certain circumstances, in order not to block the business. However, there must always be an action to solve the problem at its root, otherwise you’ll end up with an employee that edit/resubmits messages as a fulltime occupation!
There are some enhancements to the resubmit feature in the Logic Apps release pipeline, but the edit functionality has a quite low priority at the moment, which makes perfectly sense in my opinion. In this blog post, I’ll show you how you can setup and edit – resubmit process for invalid messages, using standard Logic Apps actions.
In this scenario, we’re receiving orders from an FTP server. Each time a new order is placed on the FTP server, it must be validated as a first step. In case the order is valid, it can be sent towards the ERP system. Otherwise, there should be human intervention to modify the message and resubmit it into the order process.
First of all, we need a message store where business users can modify messages and mark them for resubmit. A SharePoint document library seems a perfect fit for this requirement: it’s a well-known environment for business users, there’s the opportunity to modify documents online and by adding a custom column to the document library, we can decide what messages that must be resubmitted. Logic Apps has a first-class integration with SharePoint, so we’re safe!
Second, we need a design that allows to resubmit messages into the order process. This is done by splitting the process in three separate Logic Apps:
- Receive the order from FTP. Decouple the receive protocol, which allows others to be added in the future.
- Process the order, which means in our case to validate the order against its schema.
- Send the order the ERP system. Again decoupling protocol handling from message processing.
In case the message turns out to be invalid, it gets sent to the SharePoint document library. A business user modifies the message and sets the Resubmit column to Yes. Another Logic App is polling the document library, waiting for messages that have Resubmit set to Yes. If there is such a message, it gets received and deleted from the document library, and it’s sent again to the Logic App that validates the message.
The Validate Process
The Validate Logic App looks like this. The message is received by the Request trigger. Then, a Validate JSON performs the message validation. This could also be performed by the XML Validation action from the Integration Account. If the validate succeeded, the Send to ERP Logic App is invoked. If the validate failed, the message gets uploaded to the SharePoint document library, via the Create File action. Afterwards, the Logic Apps run gets terminated with a Success status.
The Create File action looks like this:
It’s configured with the following Run After setting:
The Document Library
The document library looks as follows. Invalid messages get uploaded here and can be modified by functional key users. By changing the Resubmit column to Yes, the message gets resubmitted!
The Resubmit Process
This process is pretty straightforward. A polling trigger fires when a file is created or modified in the document library. If the file has the Resubmit value set to Yes, its content is received and sent back to the Validate Logic App. After this succeeds, the file gets deleted from the document library.
By combining SharePoint and its easy-to-use Logic App connectors, we can easily enrich our integrations with human intervention! This edit/resubmit scenario is just one use case. Think also about approval processes, or tasks that must be completed before an automated process should kick in…
Subscribe to our RSS feed