Introducing Long-Running Processes with Frends 6.2

Hello everyone and welcome to another FRENZ webinar. Today we are proud to introduce FRENZ 6.2 with the long-running process capability as our brand new flagship feature and to maybe kick things off here I'd like to discuss for a moment why we built this feature or capability into the platform. So after years and years of building different kinds of integration and automation solutions we always felt that there was a gap when you were automating business processes from an end-to-end perspective and we actually noticed that most integration tools and solutions on the market lacked a key capability that allowed them to integrate and orchestrate processes over a longer period of time. So that means that these sorts of solutions and platforms typically failed or suffered when any sort of a solution where time was involved, meaning that the integration execution took more than a few minutes, it could have taken days or weeks, that simply was not just doable with the technologies that we've encountered. We noticed also that that building full-blown end-to-end business process automation without these long-running process capabilities meant that the actual solution itself was just a collection of slightly related workflows meaning that monitoring and of course building the solution was extremely confusing because you had no way of linking the entire end-to-end chain of events to one another in a meaningful way and of course from an error handling or operative perspective when something failed it was very very hard to resume the entire chain of execution so the entire business process because typically those business process automation solutions consisted of multiple workflows chained together so to address these issues we built the French long-running process support capability and what it basically allows us to do is a build these durable and stateful integration flows and processes that can span hours days weeks or even months without splitting them into multiple disparate workflows we of course thought about the way that we're introducing this feature and we put a lot of effort in actually implementing it directly into the core and at the heart of the french platform allowing us to extend any current integration solution with exactly the same toolkit in essence we introduced new shapes that basically allow the user to build these long-running and long-lasting processes And from a practical perspective these three new shapes that we've introduced are what's called a checkpoint state that you can drop in into your processes and integration flows that are going to persist the state of the integration execution up until that point allowing you to resume later from a manual perspective or using one of the two new shapes. we also introduced with the long-running process support. The first one is what we're calling the scheduled resume. So imagine that you're first saving the state of the process and waiting for some sort of an external event to continue the execution. That external event could just as easily be basically a timer that we run directly on the platform. allowing us to build all kinds of cool new use cases where we might be checking if a certain type of information has already been updated or perhaps has a certain type of file appeared in an SFTP folder or anything of the sort. The last new shape we are calling is called the signal resume shape and this allows you to start and continue a paused or persisted execution of another process from a completely other process basically what this allows you to do is now chain multiple processes together and even mix and match integration patterns together so imagine you have an integration where you are saving the state and stopping for an external event and the external event could actually even be an API call through an API you are publishing using the API management capabilities of the platform so How does it work from a practical perspective? So if we spend a few minutes here discussing the actual persistence point or the checkpoint shape what's happening under the hood when we are utilizing the checkpoint shape. So basically when you put in your checkpoint shape you need to define some sort of a time limit and of course the time limit can be very large but it cannot be infinite, that the process will basically save its state allowing you within that time limit to actually continue the execution and just as the name suggests the checkpoint state saves all of the data of the integration flow or the integration process up until that point allowing you to actually access the same variables the same data as you would have normally done except that now this checkpoint state is making that process stateful it's making the process durable it's allowing you to have that very long time between the initial execution and then of course the continuation another key maybe point here to to describe or go through is that the checkpoint state can now also be utilized in case of error situations. So previously pretty much your only option when executing an integration flow that went into an error was to rerun the entire flow from beginning to end, but now with the checkpoint state you can just quite easily drop the checkpoint shape into any integration flow and of course if anything fails after the checkpoint shape you can go into the monitoring of friends. find that failed instance and actually you don't have to rerun the entire integration process or flow you can restart it from the checkpoint whilst actually having access to all of the data processed so far in essence allowing you to for example change some of the messages change some of the data that caused the error in the first place thus of course recovering from that problematic situation. One key thing I'll mention here about the checkpoint state is or the checkpoint shape is that the data itself is stored locally on the friends agent and that means that you are still complying with all possible data governance and data compliance rules when utilizing the checkpoint shape but the other side of the coin is that because it is stored locally persisted on the disk of the friends agent. running that particular integration there is a certain size limit of how much persisted storage you have available at any given moment. Moving on maybe to the signal resume shape which basically allows you to now continue the execution of an integration that's waiting in a checkpoint shape for that external trigger or continuation. the intended ideology or the intended capability here is that you might have two completely unrelated integration flows that you actually want to now mix and match together like I mentioned earlier you might want to resume a long-running process from an API call or even in certain cases you might want to resume an API call from a file-based integration and the way that this works from a practical perspective is that you will need to provide correlation ids so whenever you are persisting the state or the utilizing the checkpoint shape to persist the state of an integration flow or a process you can define that for this particular process execution the correlation id is this and then utilizing that same correlation id you can resume it from any other friends process or execution depending of course on your architecture and scenario Finally maybe diving a little bit deeper into the timer resumption or the scheduled resume shape where now typically what we would assume as the use case is something that you can see actually here on the slide quite nicely where you are doing certain types of integration functionality and you need to check if something has actually or a condition has been fulfilled so typically this would be in the case where a system A would receive some sort of information and before that information needs to go to system B you need to check that the state of the information has for example changed from preliminary to accepted and now you could in essence keep on polling that particular system, that particular message, keeping the context of the overall execution always in mind, and of course only resume the execution when that particular condition has been met. So typically what you would do is most of the time utilize the scheduled resume with a decision shape making that gate on should you actually move forward that condition has it been fulfilled or not. Alright next up I would like to go through some example use cases where you would actually utilize the long-running process capability introducing those new shapes the checkpoint shape the signal resume shape and the scheduled resume shape and typically these are all use cases that span let's say more than a minute so oftentimes you we see organizations all over the place having integration flows having processes that require some sort of human intervention even in happy cases and typically these are called human in the loop processes where as an example we might have an incoming order that typically we could allow to flow straight through to our erp but in certain scenarios we might detect that hey the amount ordered in this particular order is usually unusually high so in this case we actually want to store the state of the process pause the execution perhaps alert the business owner to come in into friends check the status of the integration flow and then resume it thus giving their approval for the execution to continue. Another excellent use case in the same sphere of these human-in-the-loop approvals or workflows would be for example any sort of ticketing based system where perhaps you might have a new ticket being created that is determining or let's say informing you that there is a catastrophic failure. now in the factory and the next step of the ticket would be to have a human approve this sort of let's say catastrophic recovery procedure and now actually instead of all of that happening on the friends platform what we can also do with the human in the loop use cases is simply hook into another system's data and statuses to use those for the approval so in my ticketing example we could basically check every five seconds that has a human now come in and move that ticket from let's say the initial reported state to a cut let's say resumption or approved state and that would act as the approval for our use case this could also be something that where any kind of let's say ordering of equipment is involved and you need to have approval from your manager so you could put in that let's say order for your equipment and we detect that now the order is over a set amount of money meaning that now your manager needs to come in and accept it in the system you are using to order equipment and friends can of course now also wait for that approval within that system and once the approval is is of course received we can then continue in actually sending out the order for the equipment and complete the workflow or the automation that way maybe another excellent excellent use case for the long-running process support capabilities are any sort of business processes where quite often you have multiple parties multiple systems and multiple people involved in that overarching business process and good examples of these could be any kind of a loan application process where information needs to flow between the loan applicant various kinds of core banking systems various kinds of approval systems and of course the end result being the app loan application being approved so from that perspective that's an another really really excellent use case because now we can actually manage the entire business process from an end-to-end perspective in essence integrate the first two systems in the workflow together and wait for again someone to come in and push the process to the next state do the third part fourth part fifth part and overall end up in a situation where friends is actually automating the underlying business process and we have multiple different systems available and of course it might take days weeks or hopefully not sometimes even months in between these different data transfers in the overall larger business process in question This same principle can of course be applied for any kind of let's say configure price quote order deliver processes. This can be utilized for any sort of let's say claims related processes from an insurance or let's say health perspective. Any sort of stateful processes for example involving a consumer. using a web application so any anything you would for example use to schedule an appointment with your customer or consumer could now be utilized in the long-running long-running process feature to actually look at the bigger picture from the perspective of that single consumer instead of those disparate integrations kind of artificially working together and maybe a final good use case example could be from any sort of order or supply chain style of processes so any kind of let's say integration flows where you are working especially with edi formats or any kind of let's say legacy b2b transactions where there needs where there needs to happen uh this sort of let's say a multi-faceted discussion between your systems your business and your business partner or suppliers systems and business and typically these might be related to for example order to invoice type of processes where you're actually sending multiple messages back and forth confirming that messages have been received quoting prices for an incoming order sending out information that the order is now in manufacturing sending out information that the order is in shipping and of course finalizing that entire chain with a transaction or the actual invoice for the end-to-end process. All right and on that breath I'd maybe like to show the long-running process capability in action on the French platform and as it happens the example we're going to be taking a look at today is exactly that orders to invoice process I was describing earlier where if we take a look at our integration flow here we can see that the integration flow is actually triggered upon a new EDI orders file being received and what we actually achieve with this end-to-end orders to invoice process is that we are actually now managing that entire electronic data interchange discussion with a single business party from the perspective or the point of view of a given order and of course this process is highly highly integrated into our ERP system so you can actually see that upon receiving the order the first thing that we do is we create that order in our ERP system so we insert that order and this is of course a fairly fairly typical use case up until this point so you have hundreds and thousands and millions of these types of integrations to receive orders and push those orders into the ERP But where things get interesting is now once we start looking at the response on what should happen next after receiving the order. So in this case we of course also need to send out a response to the original orderer or the party sending out the original order file confirming that we have received said order. But then we are actually utilizing the checkpoint shape here as you can see so persisting now all the information relating to the order in our checkpoint shape and we are using the scheduled resume shape here to basically build out that polling pattern I mentioned earlier and what this polling pattern now allows us to do is actually every one minutes actually we are and what this polling pattern allows us to now do is specify that every one minute or basically every minute we are checking has the other business party now send out another acknowledgement message meaning that the first exchange of information order and order response has been successfully received and completed by the business party or by the other business partner and of course we can actually be stuck in this resumption in this polling loop for basically forever and because we are still checking does that resumption message does that resumption condition or signal exist every minute that still allows the integration flow to be very very dynamic and real-time but still last and be durable for months and months on end and of course a very similar pattern then continues where we just wait for the order for first to be of course be shipped then we might send out let's say this dispatch advice message to the business partner we are updating the ERP system we are again using the same pattern to wait for an acknowledgement message from our business partner, sending out a new message, waiting for the response, and I think you can get the idea on how we can now utilize this pattern especially to create this end-to-end process and flow, and of course here we are only following a single happy path, but the long-running process capability has no restrictions. to how and how you can actually implement your orchestration and utilizing the other normal friends integration platform features meaning that you could also split this entire execution into multiple paths each of those could have their own waiting waiting schedules or checkpoints and those could be split into further paths and they could have their own checkpoints and so on and so on and so on and so on until you end up with and full end-to-end automation of a given business process and next up let me show you why this matters now from a monitoring perspective so obviously just being able to build that from the point of view of a single order or whatever single entity you would be processing is a huge benefit but from a monitoring perspective if we open up an execution or more the monitoring view for that particular integration we can open up a successful execution and of course you can even see here that we are looking at now from the purchase order perspective where we have the partner id of the partner who's sending the purchase order as well as the purchase order number allowing me to of course now use the features monitoring features of friends to search for particular executions such as for example purchase orders beginning with 4850 and when we find that execution that we are interested in that actually now allows me to have that same real-time excellent full auditable monitoring view of the entire execution of the end-to-end business process and the cool thing about the end-to-end or the long-running pre-business process capability or the long-running process capability is now the fact that in the first wait iteration here I can actually see that because we are waiting for the response to come once every minute we've actually waited for two minutes now so we have two iterations of this loop modeled here in the flow and I can actually if I wanted to go to the first loop and actually see that for the first loop we have no result so we didn't actually find the acknowledgement file we were looking for which of course means that we did not continue and instead went for our weight shape where we basically started waiting for a single minute after that minute had passed we go back into the checkpoint and continue or resume the execution and then on the second try now we can actually see that we found the EDI file we were looking for and of course that led us now to continue the execution forward so even though you might be polling hundreds or thousands of times or even though you might have the process waiting for extended periods of time you still have all of the excellent monitoring and transparency capabilities of the French platform at your disposal to understand exactly what has happened with any long-running process implementation you have built. All right so now that we've seen long-running process support in action I'd like to maybe close out the webinar with a little bit of a recap. So what is long-running process support? It is a capability within the French platform to extend the execution time of any integration or process flow from let's say seconds or minutes all the way to hours, days, weeks and months and at the same time make that process stateful. We practically do that by introducing three new BPM and shapes. into the toolbox that you use to build your processes the first shape being the most important one called the checkpoint shape the checkpoint shape is what you use to store the state and data of any integration flow and basically telling the flow to stop until an external event comes that tells the integration flow or process to continue from the checkpoint The ways you can actually continue an integration that's waiting using the checkpoint shape is a you can manually navigate to the real-time execution on the platform click resume and thus continue the execution manually you can use a timer shape combined with a condition thus allowing you to implement these polling mechanisms that are durable that check if a certain condition is met before continuing with the execution and finally you can use the signal resume shape allowing you to continue the execution from an integration flow or a process outside of the one you're actually developing thus allowing you to combine multiple integration patterns such as scheduled or event-driven integrations into one coherent architecture. One key thing to note about the long-running process support capability is that it's also excellent for error handling scenarios and this must not be understated if you have an integration where you have a need that if the integration fails you need to be able to resume it from midway of the execution you can now achieve that by simply inserting the checkpoint shape and you can actually also modify any of the execution data in case that particular integration execution ends up in an error state and finally all of this processing happens directly within the friends core platform within the friends agents no additional engines no additional third-party software is required thus all of the existing compliance data data compliance and of course other sorts of security requirements being fulfilled automatically so as the last thing I'll mention here what we want the business benefits to be for our customers utilizing the long-running process capability is of course have operational impact meaning that we want to enable end-to-end process visibility and operational actions so rather than trying to piece together how a certain order or a piece of data has flown through multiple integrations you can now have all of that in a nice clean single end-to-end view we will of course with this introduce fewer moving parts and fewer points of failure along the way and even if something fails the checkpoints now allow us to resume the execution with the data modification capability making the integrations much more resilient to problems and finally I think also auditability and compliance perspectives are not to be understated here it is very very easy to communicate how an entire long-running business process works once you have that modeled out from an end-to-end perspective rather than those tests or disparate integration flows kind of connecting somewhere so we are hoping that this will allow you to communicate with your business owners business users in a much more clearer way that makes sense to them with the longer long-running process capability And finally of course I think this also has a strategic impact for many of our customers so this will allow us to now automate new use cases that previously were pretty much impossible or at least very hard to develop and and operate such as those approval processes, human in the loop use cases. human in the loop use cases with AI as an example are extremely useful with the long-running process support as well or any kind of let's say claims process that we typically were not able to automate in a nice way previously and of course this will allow us to reduce our risk in time dependent workflows so the workflows in breaking and also improve our SLA predictability when those business critical workflows are running because now it's very very clear that if a given order is received and if it fails we can immediately see that from the dashboard go to the execution fix it and of course end up with a happy path and a happy scenario That's all we had time for today. Thank you so much and we will hope to see you in our next feature webinar.

In this webinar, we’ll introduce long-running processes in Frends and show how you can design, run, and monitor workflows that span hours, days, or even weeks. You’ll learn how to pause workflows safely, persist process state, and resume execution reliably based on time, events, or human actions — all within a single BPMN process.

We’ll walk through practical use cases such as approvals, SLA-driven workflows, case lifecycles, and asynchronous integrations, and show how Frends eliminates the need for external schedulers, custom state handling, or fragmented process logic. You’ll also see how these capabilities fit into the broader Frends platform and API-driven architectures.

In this webinar, we will cover:
- Long-running process fundamentals in Frends
- BPMN modeling with Checkpoint and Resume shapes
- Time- and event-based workflow continuation
- Real-world use cases: approvals, SLAs, and cases
- Live demo and practical design tips 

Who should attend:
Integration architects, developers, IT leaders, and anyone responsible for automating real-world business processes.