Integrate 2018

June 4-6, London

Summary

Divya Swarnkar & Amit Kumar Dua discuss how to easily migrate from a BizTalk set up into an Integration Account using Logic Apps.

Microsoft IT (CSE) use of Logic Apps for Enterprise Integration

Integrate 2018, June 4-6, etc.venues, London

Length45:05

Video Transcript

Welcome. I hope you all are enjoying the event. I am Arunkumar. I joined the Kovai Limited as one of the founding members of India operations four years back. I identify myself as an organization growth capitalist. Currently, I’m looking after one of our products ServiceBus360, and I’m very happy that we have merit a revenue-generating product in a year’s time. So I feel privileged to introduce the speakers for this part of the session of the day.

Divya works with Microsoft was a program manager driving first class out-of-the-box management experience for Logic Apps via Logic Analytics and OMS. So she works along driving Microsoft’s strategy to move enterprise integration from MABS and BizTalk Server to Azure Logic Apps in the iPaaS.

The other person who’s joining the session is Amit Kumar Dua. He’s a senior program manager at Microsoft. He has got over 14 years of experience. He’s interested in product and technology areas that span cloud enterprise ID systems, digital transformations, Agile product, and development methodologies. He’s now venturing into the exciting space of supply chain services. So on to you, Divya and Amit. Have a great day. Thank you.

Divya: Thank you. Good morning, everyone. Yeah, I’m glad to be here back and to share our story on where we started and where we are now in terms of using Logic Apps for enterprise integration at Microsoft. So can I get a quick show of hands on how many of you here are using Logic Apps for B2B integration today? And how many are planning to use it in the next year or so? All right, cool. That’s a great number.

So let’s start with what enterprise integration means in the context of Microsoft as a service enterprise integration, provides partner integration, which is primary around B2B EDI integration. And then, we also have scenarios for systems tool system integration which is more around application-to-application integration. And all these scenarios are enabled for different business portfolios that we have.

In simple terms, we have three key business portfolios. One is supply chain, which basically involves suppliers, distributors, retailers doing business transactions with Microsoft, buying Microsoft products like Xbox 360. And we also have volume licensing, which is more around the business transactions involving purchase and distribution of software licenses. We are a software company so this is a huge business segment for Microsoft. And then finally, we have something called corporate functions, which includes areas like finance, marketing, human resources. The key person that’s involved here are employees, their families, and internal Microsoft businesses.

A key business here is treasury, where all the dealings, for example, Microsoft acquiring other companies like GitHub or LinkedIn. All of those multibillion dollar transactions also happen through this enterprise integration pipeline that we have. So the reason we are sharing this with you is that given that we are one of the largest companies in the world, enterprise integration is very critical to the business strategy in Microsoft. This is what both Microsoft and its external partners are using when they are doing their business with Microsoft, so it’s highly mission critical. It’s highly critical for Microsoft because that’s the face of Microsoft. That’s how people…that’s how businesses see us when they are doing business with us.

And to support the integration at Microsoft, this is the scale that we have. And I won’t go and read the numbers here, but most of this landscape today is on BizTalk Server. And we are on our path to modernize this to move this to cloud. And as part of that, we are using Logic Apps, and along with that their Azure services to modernize this platform.

As we are doing this, we have a vision in mind. The vision is irrespective of the platform, irrespective of what technologies are we using, as John mentioned in his keynote yesterday, change is the only constant here. But we want to embrace the change instead of following the change.

And as part of that, we have some core principles. To the center of it is that whatever we are doing, we want to make sure that we do integrations at the speed of the business. The platform should not be an impediment to the business as they want to grow, as they want to accelerate and expand. Platforms should actually support that vision. And the way we see we can enable this is by some core principles like simplifying our business, simplifying our platform, how we support integration service, how we build the integration service, how we support it. We want to simplify the entire process.

Along with simplification comes the acceleration. We are also keeping in mind that along the simplification, we are building the right to automation so that we can do bills faster, we can test our services faster and eventually, we can collaborate with our business faster. We can do onboardings quickly. And to enable all of this, along with building the product, we are also investing a lot on building the tooling and the right set of automation. We now have toolings to automatically onboard partners onto Logic Apps through something that we call self-serve onboarding.

We have tooling to enable the artifact migration from BizTalk Server to Logic Apps in an automated fashion. And all of this is to support our vision that we want to move quickly and fastly. This is again ties down to the reduced time to market, where at the end of the day, we are embracing change and we want to embrace the change in a way that we are not behind.

We are leading the change. We reduce the time it takes for us to take things from…let’s say to take our code from development to production. How do we reduce the dev op so that we don’t take days or months to test whatever we are building, so that we can work quickly with our businesses to do end-to-end testing with them, to work with them, to ensure them that the integration service that we have meets their needs?

And finally, the fourth one that I have here is fairly new. It’s a mind shift. It’s somewhat a mind shift here, where we want to share whatever we are building with our partner ecosystem. So we are one of the biggest IT organizations in the world, and we want to use that to our advantage by not just building great services, but also we want to help our products to get better, provide them feedback, work with them to share the enterprise scenarios with them.

Along with that, whatever tooling we are building, whatever accelerators we are building, we want to share it with the external community, with the partner ecosystem we have, as well as we want to learn from you guys as well, which is why I asked this question in the beginning that like via sharing, we want to learn what you’re doing so that together we can make the products better. Together, we can build better services.

Before I go into the reference architecture that we have, these are the processing stages in a typical integration pipeline that we have. This is primarily demonstrating the B2B pipeline that we have. For any platform, we have trading partners sending us messages. They come land to our gateway.

For B2B messages, we go through our typical stages where we do some exchange, we get them using some protocol like AS2 or BTF, do some processing on it using some document protocol like X12, EDIFACT, do some business processing and transformations on them, and finally, deliver it to our line of business application via…since most of our line of business applications are on-premise, we use different mechanisms to connect to those systems via ExpressRoute or BizTalk or on-premise data gateway likewise in the other direction.

This is primarily for B2B scenarios, where typically a message touches almost every stage that I have here. We have also have A2A patterns, the application-to-application integration patterns, which are more dynamic in nature and may touch one or more points in the different stages that we have here.

So let’s look at the reference architecture that we have. This is where we started. And I’ll quickly go through what we have here. So on the top, I have the external partner who is sending a message, sending a transaction to Microsoft that lands to our gateway. At the gateway, we also have a store and forward capability so that we can reprocess the message in case of any failure or if we have a DR scenario.

From the gateway, the message goes to APIM. At APIM, we have policies that allow us to do routing, appropriate routing. And from the API, the message lands into our integration workflows, where we are using different Agile services to do the processing on the messages that we receive. And then, we deliver those messages to the on-premise systems via Biztalk server.

BizTalk Server is primarily being used here for connectivity purposes. Almost all the processing that we do on BizTalk Server is now being moved on to Logic Apps. So there is no processing happening here. This is more of connectivity and also provides a store and forward capability here, where if our downstream system is down or unavailable, we can disable the send ports or receive ports, and then process the messages as and when the downstream systems come online.

Now, we have extended this BizTalk Server here. As we shared earlier, we are trying to move from BizTalk Server to Logic Apps, so we definitely cannot have BizTalk Server here forever, right? So we need a strategy on how do we move out of BizTalk Server completely. One of the ways in which we are doing it is by adding another path here, where for our line of business applications for which there is a way to connect via on-premise data gateway or via some other mechanisms, we are using another approach where we have a POP sub model.

Right now, I have a generic queue here. It could be anything. It could be WinTab service verse whatever you want to use. This is somewhat a work in progress, so we will make a decision. We’ll close on the appropriate technology very soon. But conceptually, the idea is that whatever we process at the integration workflows, we publish it to this queue. And then, we have different subscribers based on their destination. If it goes to SAP system, we have a subscriber that reads some message from this queue and sends it to the SAP system or to a file share or SFTP server depending on what the destination is.

The reason we have introduced this here is that this acts as a message box or the store, the capability which BizTalk Server is providing us here. So in case any downstream system is down, the messages stay in the queue. And once the system is up, the subscribers start again and pull the messages from the queue.

The other scenario that I mentioned we have in terms of integration is application-to-application integration. So this is how we enable application-to-application integration. As I was mentioning before, it’s more dynamic in nature because we don’t necessarily know right from the beginning what kind of processing is needed for these messages. What are the different stages these messages need to go through?

So the pattern here that we have is that we have publishers for all the applications or SAS services that we are connecting to. And these publishers are basically reading the transactions or messages from those services and then again sending it to APIM. So APIM is like the port of entry for our integration service.

From the APIM, they are routed to again the publisher or the subscriber service that we have. And depending on what the destination of the message is, where it has go, it is being read by the appropriate subscriber, being processed in the integration workflows, and then delivered to the final destination.

So here is a bit deeper diagram on how all this works. The key here is policies in APIM and the metadata. So metadata is another construct that Logic Apps provide where you can augment your agreements, your partners with additional information that helps in making decision at runtime in terms of what processing you want to do on those messages.

So here, I have basically three different verticals. The first one is APIM where we have all our policies, which allows us to make routing decision. Second is the processing vertical, where we have different Logic Apps and depending on the policies and the APIM, depending on the metadata, we do routing decisions and we do the processing. And finally, we have a line of business adapters, where each adapter takes the message and then routes it to the appropriate destination.

So let’s say we get B2B messages. One of them is an X12 messages, the item with the red arrows, and the other one is EDIFACT. For B2B messages, we typically know that this is the typical processing pipeline. Based on the APIM policies, we know that the message is either the starting point of the message, the landing Logic App. And from there, for example, for an X12 message when it came to the AS2 Logic App, we now look into the message itself and know whether it’s X12 or EDIFACT. And based on that, we are doing routing either to the X12 Logic App or the EDIFACT Logic App.

From X12, the next step, we know that it requires transformation before it is being delivered to the line of business application. And then finally, it goes to property promotion and flat file and code. So I have these discreet Logic Apps here. Like, if you will notice, one of the principles that we have is that we want to keep our Logic Apps simple and self-contained. We do not add multiple capabilities in a single Logic App. That allows us to keep this architecture extensible as well as simple.

So as we add more capabilities, as we add more protocols in this, all we need to do is add additional Logic Apps, update the policies in the APIM, and we can do routing without making any changes to the platform. So the big benefit out of this is that we are able to decouple the platform from the onboarding.

And as long as we onboard a partner, who uses a pattern that we already have established, we do not have to do any deployment. We do not have to make any changes on the platform to onboard that partner. All we need is an update to the metadata, which is just a configuration change. So this is a huge advantage and it has allowed us to accelerate our onboarding process by huge amounts. And Amit later is going to go into the details of that.

The other scenario that I want to highlight here is more around application-to-application integration, where things are not very much defined and advanced. In which case, for example, I might have a passthrough flow where a message lands into Microsoft gateway, and then it goes to APIM. And all we need to do is send that message to the line of business application. We could also have some slightly more complex scenario, where a message comes in and all it needs is some transformation based on the line of business application. And then, it eventually gets routed to the destination. So a lot of flexibility here by making use of APIM policies and by making use of metadata.

So let’s a take a quick look at how we are defining the policies in APIM. So what I have here is a simple itinerary event, which says that there are certain messages for whom the itinerary would be to do flat file decoding and property promotion. This is defined in our APIM policies for given APIs.

The way this policy maps is that the details are in my second screenshot, where for the flat file decode, we have our first Logic App, which is our subscriber context V3. That’s where the processing starts. After that, we are using the headers to read what the next Logic App is.

There is no static binding here, right? Based on what the URL, what the next Logic App addresses here, we use the address and then we route, go to the next Logic App. Likewise, from the flat file decode, we are again going to read these headers, and the headers would tell us that next you have to do property promotion. So all of these policies allow us to do dynamic routing of the messages.

The other constant that we heavily use in our workflows is metadata, where the processing decisions are being done at runtime based on the metadata. So, for example, let’s say we are in property promotions stage. What properties need to be promoted is coming from the metadata. Again, what this has enabled us is that the processing, the Logic App itself, is not tied to a specific data, is not tied to the processing. The processing data is driven by metadata. So I can use the same Logic App for different patterns for different partners because every partner probably would want to promote a different property or would want to use a different transformation.

Likewise, the line of business Logic App, we could use one Logic App and then based on whatever destination information is provided here, we can do the routing using metadata.

The other thing is about exception. Next is exception handling. This is basically what happens in case there are failures in Logic App. As I was mentioning before, we had intentionally tried to keep our Logic Apps very simple and self-contained so we do not add too many capabilities in one Logic App.

A Logic App should act like a micro service doing something very specific. And what that also allows us is to simplify exception handling. If a Logic App fails here and we have a scope, Run Scope, if this Run Scope fails, we go to the Failed Scope and then enumerate what are the failures that have happened here. Using the metadata that we are pushing onto these Logic Apps, we extract properties that are relevant for business, and then we send all of this information to another Logic App, which sends all of this data for our hot path monitoring, hot path monitoring and alerting scenarios.

So let’s see how we are doing management and tracking for our service. So we have two parts here. One is the hot path. As I was mentioning in the previous slide, we have exception handling for all our Logic Apps. And in case, there are failures, there are issues, there is a Logic App that writes all those events to an Agile function, which then pushes all the data to a ticketing system.

Now, we have different businesses as our subscribers here. Because we are augmenting whatever failure event we are getting from the Logic App with enough business information so that the subscribers can read to the data that is relevant for them and take action on it. Along with the business subscribers, we have platform also as a subscriber here. So any failures that are specific to the platform, the platform team gets them and they take action to resolve those issues.

Then we have the warm path telemetry for which we use the in-built Logic Apps capability to push the data both to Event Hub and to Log Analytics. Log Analytics data we are using for our dev ops scenario, where we use the OMS, our dashboard for monitoring and troubleshooting purposes. We also use this data for doing some of the business alerting.

So in our hot path scenario, we do not have the ability to correlate across multiple events and to do business alerting on things like delayed MDM missing and all missing acknowledgments. For those kind of scenarios, we rely on Log Analytics. But to keep ticketing centralized, we still push those events back to the Agile function, and then it goes into our ticketing system.

For business tracking, we already have our business tracking solution that we use for BizTalk Server. And by using the data that is ingested into Event Hub, we are able to leverage the same tracking system we have for Logic Apps monitoring as well.

So where are we in terms of our migration? We start last year when we were here, we have onboarded eight partners with 100,000 messages per month. We have done a lot in the last one year. If you look at the numbers and you’re wondering that on one hand, we are saying that we want to accelerate but at the same time, the numbers are not that huge, that’s because we are also building the platform. We are also building the service. As I was mentioning, we have principles to simplify things as we are moving. We want to simplify and accelerate our service.

So a lot of effort in the last one year, one was to build the platform. There were product capabilities that we were relying on such as batching, such as disaster recovery, which were delivered in the last one year. So after they were delivered for us to use them in our services, it required some time.

We also wanted to build an end-to-end service management and telemetry system so that we are not just scoped down to our platform, but we also provide an experience, which is an end-to-end experience when it comes to managing our services. If there are three different teams in this end-to-end pipeline, we don’t want our business to go to three different portals to know what happened to their message. We want to provide a consolidated unified view of what’s happening to their transactions.

So we have been investing our efforts and time in doing that so that we are ready to open the floodgates and onboard as fast as we can. So which is why, like you, you’ll notice that in this quarter, we have plans to onboard a lot more partners and bring on a lot more traffic onto the new platform onto Logic Apps. We are still not done yet. We are still going to look for more features from the product team. One of them would be concurrency control and integrated service environment and others.

So in terms of future considerations, as you’ve seen, our numbers, our integration numbers, we have a thousand plus partners. So the question is given the integration account limits, today, one integration account is not going to be sufficient. Today, we just have one integration account. So a lot of discussion has happened around using single integration account or moving to multiple integration accounts and using them for business.

The downside with that approach is one is, of course, cost. The other one is if it moves to different integration account, we now have to use different set of Logic Apps so that is an additional unwanted overhead and maintaining somewhat duplicate Logic Apps just because we need different integration accounts. We eventually decided to stay with single integration account for now, and the reason was that we have been talking to the Logic Apps team, and there are plans to increase the limits for the integration account, which might automatically solve this problem

The other one is that on BizTalk Server, we have partner configurations, which means that if we have a partner, let’s say Dell who has a global presence, we have a configuration for each of their locations, whereas on Logic Apps, what we have is partners. So even though the numbers look like a thousand plus partners on BizTalk Servers, it’s actually going to be lesser on Logic Apps due to this improvement.

And lastly, we are ready with the migration strategy that if we eventually have to move to another integration account, we at least have a path where we are going to leverage the API’s logic on integration account to automate this process and make it as smooth as possible.

Finally, the other key capability we are waiting from the product team is around isolation and predictable SLAs. So this is particularly needed for some of our very business-critical transactions that lie under our treasury portfolio. They have very stringent SLAs of 15 minutes which includes the time to recover if there are any issues. And if we don’t do that, given the dollars involved in these transactions, the penalties also could be multi-million dollars. So this is like super critical for us and we are going to wait for the isolated offering to come and use that for our treasury transactions.

Stringent SLAs, these need isolations. There are also some businesses we have in Microsoft, which are very high value and which also are very time critical. So, for example, end of the fiscal year or end of the calendar year, supply chain and real businesses have want to do business as close to their closing time as possible because that’s the revenue for Microsoft. If we have bigger SLAs, it means that the window of their business reduces. So we want to provide this as an offering so that businesses who want stringent SLAs who want to leverage the platform as closer to the closing time, they have this option to use it.

All right. I’ll give it to Amit who will do the demos.

Amit: Thanks, Divya. Wasn’t it amazing? I’m not talking about the file. I’m talking about the migration journey. All right. I’m Amit. I’m going to walk you through some of the interesting stuff here. Divya talked about the vision, the focus areas. A couple of them I’ll be emphasizing on, simplify and accelerate, and then I’ll walk you through a couple of demos we have. I think we have 15 minutes left, right?

Divya: Yeah.

Amit: Okay. So I’ll make it quick. So given the vision we have of integrating at the speed of business, simplify and accelerate are the two important focus areas we are looking at. So when we talk about those two areas, we have to understand what all processes do we have to migrate our BizTalk infrastructure to Logic Apps, and then how should we support our integration platform on an ongoing basis given the scale of partners, the artifacts we have presently available. And every year, we receive hundreds of requests to onboard the partners. So we have a process of onboarding to support.

So when we talk about the migration process, typically, this goes through the planning, designing, artifacts development, testing and so on, and then, we move into Logic Apps. So earlier, we noticed we used to take one month for migrating one single partner to Logic Apps. So that was a matter of concern for us. And given the number of partners, which goes to the tune of 1,000, right? So you can imagine how much cost it can be.

And not only that, once the partners are migrated, we envision the onboarding process also has to be running efficiently because we receive hundreds of request every year. So that also we took into consideration, thought of order diligently and workaround. So what do we see as a part of migration process? Artifacts development, testing, and end-to-end testing are the recurring activities, where do we see TPM setup, itinerary setup, MAB development, and other development activities. And then, there are some testing activities which are repetitively happening.

And then, when we talk about the onboarding process, which is an ongoing process every year, so there is new partners getting onboarded and testing with existing partners. And those partners is quite repetitive.

So we focused on those activities and came up with a set of tools, migration tools, and self-serve onboarding portal which Divya talked about. So this is how we are simplifying and accelerating our journey to Logic Apps and then supporting our platform there.

So the migration tool, we are in pursuit of building more and more tools around that. So far, we have built two tools there. TPM Migration tool and A/B Testing tool. TPM Migration tool, we have in demo I’ll be showing you in a minute. And then, in terms of onboarding experience, we are building for our partners using which they can integrate this system with our system. But we have the screenshots available so we will show that in the interest of time. But definitely, if somebody is interested to know how that experience looks like for our partners, we can meet offline and we can walk you through that.

So let’s look at the TPM Migration tool demo. So this is how the tools looks like. So what it essentially does, it takes the TPM artifacts like EDI, AS2 increments from BizTalk Server and move it to Logic Apps. So I have a few sample artifacts which got created here. Tens of partner profiles got created here, and some of them are extra, like we may have assigned these to an EDI artifact.

So let me just show you the Logic Apps also. So this is how the dashboard looks like on Logic Apps. There’s nothing there at this point of time. You will see all these artifacts getting migrated within a matter of minutes with the help of this tool.

So I’m moving on. So this is the first kind of the tool, which introduces us the features. And then, it talks about which BizTalk Server is a source. So it is asking you what is the server name of the BizTalk and which database it is going to connect. These are the fields which are pre-populated there already. This is my laptop server name and database. Then, moving on and then searching which partners we want to migrate. So it is listing down all the partners which are presently available on BizTalk Server like Contoso and Fabrikam from different countries. So I select a few of them, Contoso Australia, Belgium, U.S., and Microsoft and then, Next.

So it is preparing some JSON files intermediately because those JSON files are for the use to migrate the agreements on the other stuff to Logic Apps. So it is now showing you what the progress. Then, it asks you which all agreements you want to migrate under those partner profiles. So I select a few of them like one of them is extra AS2, EDIFACT, and one more extra that I can choose, and then move on.

All right. So it is preparing another JSON file between…now, it is asking for the schemas. You generally know now schemas are configured in EDA agreements to resolve the message type, right? So I’m just choosing some of the schemas here. So this is the one I chose, and I can choose this one because these are the schemas I configured in my agreements and say Next. And then it is asking which way do you want to migrate? It is asking the Azure account, so I need to log in there with my account.

Now, it is asking an option of which subscription you have. I’m choosing one subscription on Logic Apps, and then which resource group under that, the integration account I have created, which I showed you which is completely blank at this point of time. So I’m choosing that integration account, and then it is reconfirming. Which all artifacts do you want to migrate? I chose all of them in one go then say Next. So the process has started.

Now, we’ll see in the next two or three minutes, all these artifacts are getting migrated. Okay. So there we have the certificates. I just refresh this account in a while.

Divya: So this is a tool that we’ve already published, and we are going to have a link towards the end of the slide. So if you’re interested, you can just download it and use it in your scenarios.

Male: In the case that our business partners like to see the marking setup we’re able to ask here [inaudible 00:38:25].

Divya: Let’s take this offline. We want to share more and more tooling with the ecosystem. So as Amit was mentioning, we are also building tools for A/B Testing between Logic Apps and BizTalk Server. If there is an enough interest from the community, we will open source that as well. We have also built a self-serve onboarding tool, which allows us to onboard partners via our dashboard. And then, behind the scenes, we use similar APIs to upload these artifacts into an integration account.

Again, if there is enough interest, we would definitely open source the tools that we are building. So reach out to us and let us know if you’re interested.

Amit: So it is taking more than expected.

Divya: So I think you have to believe us that the tool worked then. The artifacts were uploaded in the integration account.

Amit: So our tool is, yeah, it is showing 60% progress. So it has migrated two schemas by now. In the meantime, we can just talk about and switch over to another toolset, which we made for our partners to support the ongoing onboarding process. So let me just go there. So, as I just said, we have the screenshots available for that. And definitely, we can walk you through the demo post-test. In the interest of time, I’m not going to do that.

So this is how this portal looks like. Since we have many onboarding requests coming every year, so what we have made, we have completely automated this onboarding process end-to-end right from partners creation to each setup in different systems like BizTalk and now it is Logic Apps, of course, Logic Apps and SAP. And we have enabled different business processes in which all these partners are getting onboarded.

So this is the first screen which a partner gets when he comes to this portal. So he has to provide the AS2 IDs. And then, he can choose which transport protocol like AS2 ID, VAN, or HTTP. So AS2 is just one of them. So when he is choosing AS2 ID, he can provide the AS2 ID and URL and then certificate.

That’s what it is. We are not asking. We are standardizing like encryption advice of everything. If there is any special need, we have a backend process to support that also. So this standardization covers more than 70% to 80% of our onboarding requests every year. So it is asking all these details for production and test environment, and then it asks for EDI identifier. Here, we have XML X12 and EDIFACT as an option. So if X12 is chosen, then ISA IDs and qualifiers are asked. And then, it asks virtual business programs.

As Divya talked about, we have multiple business process being supported on a platform. And onboardings are happening on those business processes. So we are asking which business process you want to onboard, too. So there… in this screenshot, fully packaged program is one program which is given to our partners, essentially the distributors. They can onboard to these programs, so this is just one sample given here on the screen. I can choose which are transitions you would like to do under this program, and then he stays on board.

The moment he stays on board, within a matter of minutes, he gets onboarded to our large integration platform, essentially Logic Apps and SAP system. And then, notification is sent to the partner, and then he can go live once testing is done. This is only one feature which we have showcased today. But we have multiple other features available on this portal like end-to-end testing and everything, which is given to the partner using which he can pace his onboarding process as per his own convenience. So it’s a self-serve and self-paced experience given to the partners. So this is very much from an onboarding standpoint.

So as I said, we are always available for the next two days. So anybody can approach us to know more details around this. So, in the meantime, let me just go back and see Logic Apps. Still, it is in process.

Divya: So we are out of time but these are what our learnings have been. And if I have to summarize, Logic Apps is like a double-edge sword. So you have to know how you want to use it. There’s a lot of flexibility. Depending on what kind of workflows you are building, pick the right pattern. Pick the right constructs. As you’re using Logic App capabilities, look at the Limits page to understand the limits around the number of action executions, number of calls you can make externally, and other things.

Also, what kind of messages are you processing? Are they single messages? Are they batch messages? If you have a batch of 10,000 messages, do you want to process all of them in parallel or you would rather like to control the concurrency that the platform provides? So again, there are capabilities provided by the platform, and there are a lot of NOPs provided by the Logic Apps platform.

Think about how you want to bill your Logic Apps. Think about how much parallelism you want, and how do you want to control the executions. So I won’t go into the details of everything here, but you can reach out to us if you have any questions on any specific point here.

Amit: So, in the meantime, I’ll check if the migration is completely done. Yeah, I think it’s coming up. So let me just go to the integration account and show you all those artifacts. Yeah, here. So we have four schemas migrated, one set of ticket, four partners and four agreements. I can show you the details any time after this session. Thank you so much.

Divya: Thank you.

Download Presentations

Fill the form below to get all the presentations delivered as a single zip file in your mailbox.

please wait …..

Interested about future events?

please wait ...

Back to Top