LogicApp is all about the cost associated with every action, polling is one such thing.For example execute a logic app when the blob is added to blob storage every three minutes.
This polling will execute every three minutes throughout the year and even after that, there could be a potential three minutes delay in processing messages.
We should try to make an interface event-based. This is a real-time and more cost-effective way.
Following are high-level steps I will not go into details:
2. Create UserAssigned Managed identity [ USMId_01…
Biztalk-BRE business rule engine is one of the frequently used components in BizTalk. The question is why we use it in BizTalk and then try to find a corresponding solution approach in the logic app
BRE in BizTalk helps to modify Orchestration behavior at runtime without the need for the redeployment of Orchestration.
BizTalk-BRE is based on the RETE Algorithm ( Ref ) which has benefits in the case of complex multi-level rules execution. But most of the time we have simple rules which can be implemented using if-else logic
There are many ways to implement business rules based on…
LogicApp is a PaaS model but still they provide three different deployment modes. We will try to understand those options and when to use them.
Option1: PayAsYouGo Model (pay for each and every action)
Option2: Integration Service Environment ( pay monthly/hourly and all LogicApp deployed in ISE will be accounted for)
I have a scenario where a lot of data processing happening in Azure Function and it can more than 2 minutes to execute on a busy day. Standard HTTP action has 2 minutes of timeout which failed during load testing ( yes even in azure PaaS services we have limitations and timeouts).
How to solve this problem, well there are three approaches we have ( at least I can think of).
Approach1: Redesign AzureFunciton processing to limit the scope of data processing so that it always returns within 2 minutes timeout. …
Correlation is a frequently used approach in BizTalk to manage interface where the downstream system takes non-deterministic time to process messages and respond back. BizTalk provides correlation configuration as part of Orchestration and many things are managed in the background using the MessageBox SQL database. But the key point is we have promoted property that is matched for incoming message and waiting for orchestration, to link correlated message.
How to achieve this in LogicApp where there is no MessageBox SQL database?
We can use Blob storage to solve this as described below:
Step1: LA01 — Before sending messages to downstream…
LogicApp can be triggered from outside and linked with each other by HTTP calls but this all gives a synchronous approach to message processing. But often we need to decouple source and destination systems, as we integrate more systems having different downtime, downstream downtime, parallel processing capacity, a mechanism to save messages and process the same on-demand at a later stage.
Let's try to understand with a sample scenario:
Interface Int01 with two sources, one processing ( data transformation), and three destination systems.
Solution 1: Create two logic app for each source and perform processing and send to three destinations…
An interface solution design where we can potentially have 50 logic app. All the logic apps have hundreds of messages to process and almost similar data flow moving different data updates from source to destination based on dynamice365 business events.
There are four major API connections in Logic App
I can create one API connection for each of the types above and use this across all LogicApp. This will all work fine but can potentially fail in production. …