Merge Robotic Process Automation (RPA) With Workload Automation: And How it Helps

So hi everyone. Thank you for opening this recording of our robotic process automation session. This is a re recording of our session from yesterday's Stone Branch Online series. Unfortunately, if you were attending or attempted to attend, you may know that we had some technical difficulties which kept us from, broadcasting the audio as well as recording the audio for later viewing. So instead of simply apologizing, we thought it might be best to create the recording again so that you have the benefit of the full session, including the questions which we will reread and readdress at the end. So without further ado, I will introduce our presenter today Helmut Damen, Director of Product Management at Stonebranch. So go ahead Helmut. Hello everybody and thanks again for your patience and your capability of accepting some of technical issues that we had with the GoToWebinar as Marissa mentioned. So I'm trying to do my very best to really try and tell the same story that I did in yesterday's presentation. You may have identified in case you were part of the presentation that today we might have a bit of a different story because once you do it a second time, you always have the chance to optimize what you thought did not work okay. But generally speaking, you're gonna receive the same content and the same questions and everything as of the yesterday session. Before we actually gonna start adding going into our main topic, let's do a little recap on what we've seen so far as part of the StoneBranch online. And basically, those of you who participated in the introductory session in the middle of May may recognize this slide and may especially recognize the commitment of our CEO, Ciuseppe Damjani, in his session to say what Stone Branch is going to be focused on is investing into what matters most. And as you've seen in probably some of the latest Gartner reports or whatever, here is a list of some of the topics that are considered most in the marketplace and, of course, are the ones that StoneBrench is going to be focused on. Today, in our session of integrating robotic process automation and WLA, so workload automation solutions, we're mainly focusing on orchestrating workflows across any application or platform as it's illustrated here. In the sessions previously already held, you have seen a number of those topics in a variety of detail in between. So basically, you've seen capabilities for centralizing automation on prem and in the cloud regardless of where the actual infrastructure is gonna be located. You've seen some, let's say, information and details about digitalization especially by using real time automation. You have also seen some capabilities of creating the ability for anybody to automate and that was mainly the focus of the session of my colleague Moritz earlier last week, which basically introduced the capability for our universal integration platform or our universal automation center by using the universal automation platform to integrate to any application and also integrate with any application regardless if the integration was enforced to be northbound or southbound or whatever the current definitions are. In the remaining part, you're gonna see sessions coming up held by Brian Hardy, one of my colleagues in our product management organization that shows a lot more details on orchestrating issues and basically using native cloud services for provisioning the infrastructure and making the environment ready for cloud and on prem or truly SaaS based environment. From a technical point of view, I just want to make one little change to the slide originally presented and that is basically I want to change the investing into building what matters most because investing is just one thing or one side of the coin, but building is basically the requirement that we now have as a technology department within the organization of making sure that whatever has been supported by the management level of Stonebridge is now going to be built on a technical level by providing the necessary functionality, features, infrastructures, and solutions for supporting the services that are provided here. And one of those topics regarding orchestrating workflows across any application or platform is basically the topic that we're going to dive into today and we are basically going to look at merging robotic process automation with workload automation and how it helps. Now, there is a side note here that says sample implementation with UiPath and that's basically just used as a sample. That kind of integration is also already available for the RPA solution of Automation Anywhere and it can be made available for any other of the automation solutions. And we're really going to look into some of the details within a minute when going through some explanations and other topics. Hey, Helmut. Yes? Quick question. Can you move the little box containing the info about our call off of the presentation screen? I truly can. Oh, beautiful. Okay. Thank So, going into the details, this is what the agenda of this session is going to be. We are going to talk about differentiation and actually I have to admit, while I was looking at the differentiation between robotic process automation and workload automation solution, I more and more saw that there are a lot of similarities. There are a lot of differentiations as well, but it becomes very obvious and we're gonna see some, let's say, details or information provided by Gartner actually this month or last month probably that really make it obvious that there is a need. There may be a benefit and there's definitely a increase of efficiency by integrating workload automation capabilities with robotic process automation capabilities and basically supporting or helping to dissolve the limits that either of those solutions might have. Sorry. For we're gonna also take a look at what we call the universal integration platform, which is a long term existing solution as part of technology, as part of our universal automation center, and we're going to do a quick recap on the scope and the functionality here, because that becomes important when you start integrating or orchestrating any kind of application, because usually those applications need to be integrated by any kind of API command line functionality, and also these applications to provide a more southbound integration will provide the necessary APIs to be able to control not only the application, but also allow the application to control whatever the workload automation engine is really going to be and is going to do. Now, of course, this is all gray theory as people say, So necessarily, we're gonna take a look at how does it work in real life and basically, we have prepared a demo session that is running in one of our cloud based environments and that demo session has basically been built to show the flexibility and the ease of use for integrating a variety of applications. So we're gonna look at of course, we're gonna look at RPA integration. So we can have a robot created and that is mainly focused on SAP and is opening the SAP GUI and then introducing additional missing, so to say, data into the SAP customer environment. And it also allows us to illustrate or demonstrate integrations into the ServiceNow application and some integrations into a hybrid environment by moving data into the cloud, validating that the data has been successfully received in the cloud and is available in any of the either Azure Blob Storage areas or in the AWS S3 environments. So, a variety of integrations that is going to illustrate that it's not only GreySeries but that it's really working and existing and available in real life environments. Once we've gone through that demo, we basically gonna finish the stuff up with drawing some conclusions and opening it up for question and answer sessions. Of course, at any point in time, you can raise questions in between, but as this is a re recording, that option is probably not available, but it was part of the original demonstration. So let's take a look at a different station, a similarity, integration points between RPA and WLA and basically, we're gonna start and of course again, we're using UiPath as a sample here, but that is available basically in the same architecture basically in any area. Here is the latest twenty nineteen market analysis from Gartner about RPA tools and the key message here on the left hand side, although this is not Gartner, but UiPath itself, is basically the importance of robotic process automation is dramatically increasing as customers, clients go from a traditional IT environment into a flexible environment structure and start more and enhancing the digitalization of their applications and environments. One of the key elements for that is because RPA makes it very easy for non IT users to create basically automation rules, policies, scripts, whatever you want to call it for a variety of today manual functionality and the robot usually is capable of doing that in a far advanced speed than any human being will ever be capable of doing that. And we're going to tell you a little story when we go through the demo. We're going to tell you a little story because this is one of the experiences that we made as well when building our robots and integrating the robots into our USC solution. Now, one of the things that Gartner also mentions as a restriction, as a not necessarily a negative, but something for RPA solutions to consider is basically the four points that are listed on the bottom right of the screen that the integration features are not robots. And basically, they are in no means a digital or intelligent workforce. Now, the robot itself may be considered as a digital workforce because it takes on digitalized all the manual work and efforts, but the actual integration into the application is not necessarily a digital workforce, but it's just a base requirement for a robot to be capable of doing what it's supposed to do. Now, the second point is and I think this is really a focus where WLA comes into play, RPA does not easily and in parenthesis, is not necessarily focused on automating long running processes because if you look at for users of our UAC environment or any other workload automation environment, you know that workloads, workflows can be extremely complex. They will have a lot of dependencies. They will need certain activities just in the right place and that right place may be event driven. It may be time driven. It may be just dependency driven, so meaning a predecessor has completed successfully and is ready. So that will kick off whatever follow-up process it's going to require. That is not really the focus of robots, but that is a classical focus and a classical technology used in any of the workload automation tools available. So the conclusion drawn out of this is basically that RPA tools are just one element, one additional element of the integration at DigitalOp's automation toolbox. And that is definitely a very true statement, because if you look at the workflow that we're gonna show as part of the demo, you're definitely gonna see that it takes a lot more of capabilities and elements and technologies than just one robot doing a particular task or a particular form and we're gonna see a description of what exactly robots are intended to do anyway. So, the most important part from my point of view is that RPA needs to be very well considered when to use, where to use, what for to use. Because once starting to introduce RPA technologies into your environment, you're going to enter into a, as Gartner says, into a long term technical depth. And it's more of entering or creating it than overcoming it, which actually is usually what you tend to do when introducing automation technologies or automation solutions. Now, the reason for that is that most of the no, basically any of the RPA tools and I do agree artificial intelligence moving along and becoming more widely spread may change the game in a certain way. But as of today, the RPA tools are all GUI based. So basically, as soon as the GUI changes of the application, it may require an adoption of the robot itself because information may not be where they were originally supposed to be and the robot will fail or will no longer work. That's one of the other issues is making sure that you are aware of a robot failing and understand what is the reason for that robot failing and that hopefully and ideally without your operational responsible people having to switch between three or four different tools before they're gonna find out because if that really happens, we are back into that silo approach. You look at workload automation, so no. Workload automation is everything is okay and it just says that the robot failed. So somebody needs to look in the robotic solution and say, what happened with the robot? So you have suddenly, you have several people and and and a lot of communication going onto this. These are just things that need to be considered when and before moving into a certain technology and I think what we're gonna show is there is quite some capabilities within workload automation that can really ease that decision, make it much more fact based and really support a variety of solutions for not entering into a particular issue or scenario. So far, so good. Looking at the structure of RPA and also looking into the potential and required integration points, we're basically gonna look for all the leading RPA tools. We're basically gonna look at a equal or very comparable technology. They basically all consist out of three major components. So the first component is basically and in UiPath it's called Studio and Blue Prism or automation anywhere, it does have a different name and I actually I can't remember what exactly the name is, but basically you have a component that is supposed to design your actual automation process or your actual automation to fulfill your actual automation need. And that has and basically, all of these tools have really a great technology that makes us believe at this point in time, it's not really the point that we need to start developing solutions or integrations that help us to better create robots than those companies can do. So we believe they have a great technology of doing so because it's basically in a lot of cases, it's really no code development, which makes it very open to any kind of non IT business users. Having that functionality, it really increases the adaptability or the acceptability for automation solutions because people can develop and integrate and maintain most of those solutions by themselves because they don't need to have any specific development capabilities in order to do so. And the other important thing and that helps in providing a no or low code alternative because as I already said, it's all GUI driven. So you basically gonna have something that is gonna sit on the shoulder of the end user and is really gonna track what the end user actually is doing and creating any kind of script technology driven policy, name it with whatever you want to name it, piece of code that is then gonna execute as a robot. So, very strong capabilities in all of the major tools in that environment. So, for someone like Stonebranch, no reason really to invest into developing something and believe that we can do something that is much better than anybody else and make us very unique. And I think we need to provide the capabilities for integrating these robots into whatever the process definition is because process control, process management, process alerting, and all of those topics are basically key features that we provide in the workload automation arena. So the second part is in UiPath, it's called the Orchestrator. Same technology is available in Automation Anywhere or in Blue Prism and most likely in any of the bottom left corner technologies in the Gartner Magic Quadrant as well, is where you in the orchestrator, you provide technologies for deploying your robot. So deploying basically means, okay, you have a development environment where you're gonna do the development of a robot. You go do testing and things like that. And then you have to deploy the robot basically to make it available in whatever environment you actually wanna perform the automation. And of course, you need a technology to manage and monitor the execution of the robot, but this is all related to a particular robot. So there's not easily and I'm not saying there's no, but there's no easy implementation of making robots and other process steps dependent from each other. So basically say, okay, I wanna start that particular robot. If that particular file has arrived in this particular directory and has been put there from this particular task or workflow. So integrating that is basically the key of integrating and that's not a differentiation. It's basically really integration or similarity. Here, the bot is gonna be deployed and with the workload automation, the bot is gonna be integrated into a larger picture. Now, having done that, we basically come to the last part and here in UiPaths, it's called the robot itself. And basically, the robot itself is what is referred to as a digital worker, so to say. It actually executes the bots. It does do that in attended mode or it can do that in an unattended mode. And it's widely platform independent, so I actually figured out that there is a variety of tools that have the capability of creating bots for a classical mainframe, open parenthesis, legacy environment. So from that point of view, there's a great flexibility in creating and adopting and managing those bots. Now, if you look at it, as I already said, this or an equivalent structure applies to all the RPA tools in the market. So that means having done an integration once for one particular supplier may dramatically ease up the process of adding this technology into another supplier or another manufacturer environment because there's very limited things you have to change. And usually, there are different methods of authentication. There are different token technologies for connectivity. And there are a few different API operations that all these tools supplies, but this is definitely for somebody who has a limited even scripting capability. That is basically no point and these are the two points where we're gonna start or develop or implement the integration between RPA tools and actual workload automation tools. So from that point of view, there's a quick summary to be made for the differentiation or integration between RPA and workload automation. And of course, I agree. This is of course a subject view from the WLA perspective, but basically, the RPA itself is driven to do in a very fast way, repetitive, tedious, rules based task, and to a large extent, RPAs in the past, and again, artificial intelligence may change that game, but they have been driven or focused on data manipulation, adding data into a certain environment, manipulating data within a certain environment, adding information or extending the data within a particular environment. So a variety of things, but mostly related around data and its availability. It definitely replaces human labor with bots because you might know with anything like workload automation, at a certain point, you love that feature that pretty much everybody has which is an action required task. This is what we call it in UAC, but basically, the general term is a manual task and that manual task basically ensures that you stop the workflow and you make sure that a human being basically has to do something to approve your data, to manipulate your data, to consolidate certain data so that the data structure becomes ready for whatever the next process step is going to be. They do that in a very, very high speed and I can give you an example. One of the key challenges when we go through the demo, one of the key challenges we had in the beginning of integrating a robot into our process was the robot was so damn quick that you really couldn't see anything. I mean, you saw the robot starting. You saw the robot ending. You saw that it had a success, but there was no capability to really see what exactly is it that the robot is doing and is he really doing what we expect it to do. So slowing the robot down so that it becomes visible because part of what we're gonna do in the demo is gonna be show you how the robot operates in an SAP environment is basically by reducing the speed of the robot and giving us the capability as a human being to really look at what the robot actually is doing. The second thing is they are all surface GUI level driven, meaning that gives them the capability to see what a human being is doing within a particular user interface and then create a automation perspective for repetitively automating those user interactions and basically ensure that there is no manual failure or any any accidental errors, typing mistakes, anything is going to happen when it is done by a robot. Now there key element or limitations from what we've seen and heard from other customers so far is basically that they have no or limited overall process orientation and consideration. The automation capabilities are focused on an individual bot. Yes, there are always capabilities of connecting individual bots to each other still automate it, but it's a pretty complicated process of doing so. And that they usually have no or limited external automation, so they can't really understand events and act upon certain events be it in a web service, be it in an application, be it in a database, be it anywhere or be it just a normal file event that certain input data becomes available. So, basically, they have no capability of looking at these external process steps and decide now is the point where I have to introduce the bot. And again, that was already set. Requires adoption even without functional change. It may require adoption because the GUI or the layout of a certain part of the user interface has been introduced to you. So you need to keep that in mind and in consideration that this is something that you have to look at. In the contrary or similarity, basically, these are most of the holds or limits that workload automation covers. We do things on an enterprise level. We do have a totally hybrid approach. We don't care if that robot runs on an AWS provision server, on an Azure provision server, if there's some logic apps or AWS batch in between or something like this. We have a truly enterprise level hybrid approach for a managing a process. Again, process focused. We do workload automation tools usually or good workload automation tools do things in real time. They don't have to have any kind of daily plan. An event happens, be it in a file event or be it any kind of other event. An event happens and it triggers off the according the related process automatically. So no time delays, no inefficiencies between stopping a certain process step and starting the new process step for safety reasons because you want to introduce a time slot in between to say, I'm not sure if it's really gonna be done by two thirty, so let's give it another ten minutes. So I'm sure that the file has arrived, that the manual action has been completed or anything like this real time and it's totally event driven and it provides a complete dependency structure. So basically, it's all focused on streamlining the enterprise wide process itself and it's very much focused on robustness and not necessarily that much on providing the latest and greatest technology capabilities that may be available, but more on making sure that things happened in a reliable, auditable way and sequence instead of just trying to be as fast as possible. So, as you might see hopefully, I was able to explain that there is a lot of similarities between both tools or both solutions and areas and there's also a lot of differentiation between both tools and that's usually the how do you say that? The the mathematical formula that makes a lot of sense on the integration part. It's basically WLA functionality plus RPA functionality equals great content workflows. So that's basically my conclusion. And coming to the next part, we now need to look quickly at something that we're going to provide as integral part of the Universal Automation Centre. Currently, we call it the Universal Integration Platform and that basically and I'm referring back to last week's session from my colleague Moritz and you've seen a lot of the parts. So I'm really going through that relatively quickly and technical details can be asked, answered, detailed on any point in time basically contacting one of your StoneBranch representatives. So the universal integration platform is a feature or a function that we provide as part of the Universal Automation Center probably for the last three years already, and we are enhancing it year by year with the upcoming releases by providing additional or enhanced functionality that we have identified by customer usage on the one hand. Customers coming in and say, hey, you got this great feature but we would need this type of enhancement to that feature. So a lot of the field definitions and field visibility options in the universal template have been coming out of that. And of course, our own people and consultants and solution engineers are developing a variety of of integrations and we're gonna come to that a little bit later and they have delivered their input. So it all starts with a universal template which is basically considered the task form that allows you to create a new task type. In our example here, we're gonna create a new task type called the UIPass universal task. And basically, it does have three major informations available. So number one is, you need to provide a script and you can develop the script wherever you want. If you have, for example, any kind of development library that eases up the process of developing it, it's pretty simple. We currently do that by copy pasting it after it has been successfully developed into that environment, but that is gonna be on the list for enhancing it as well for providing different capabilities of uploading ready made scripts or whatever. So the key element is that you have a variety of, let's say, scripting languages available. So we basically support anything that you can do on a particular platform, but we also do support and we call that the agent type of any. So and in our example, we're using a Python environment and we're gonna spend a few words in a second on why we have decided to do so. And basically, then you're gonna provide the script that describes what is it that this particular type of task has to be doing. So if it's any kind of API driven, it has to connect to the API or it has to connect to the application. It has to authenticate versus the application. It has to provide certain credentials. It may have to provide certificates or anything like this. And then, it has to based on the functionality of an API for example, it has to decide and run through a variety of functions and features that the API provides. It helps you to manage processes that are executing in that particular application. So the second part is you see this Windows script file type down here which is called UAPI and you might know and recognize that UAPI is an extension that is not provided by neither by Windows nor by Linux or whatever. So we are adding that extension to any of the given environments because we are providing a full Python three point six environment as part of our agent delivery. Because in doing a lot of template development, one of the biggest issues that we always identified is figuring out that on that agent or that server where we wanna run a particular type of task, there is not yet any Python available. It's a different Python version available. The customer is not necessarily authorized of installing new software, so it becomes a very complicated process. So we decided we're gonna package Python three point six and we're upgrading the version as we identify vulnerabilities and anything like this. But we basically gonna provide this capability and for making sure that any template, any task type understands that this is the StoneBranch Python. We're adding the file extension of UAPI to make sure it's a universal agent Python, and we also ensure during the installation process that it's clear to the system where or which path to be used to find all the Python modules that may be required for executing this particular type of task. Now, looking at that, we have basically and I just extracted a few lines of the script because we don't wanna do we don't wanna go through any of details of the script. I think you all know that better than I do. But basically, this is parsing the variables and you see some of the variables that become a different meaning. So, no, not a different meaning that become a different importance in a second when we look at field definitions. But basically, what we're doing here, anything that we receive from the template, we're passing that and making that available as variables, as dollar variables which means they are not necessarily UAC variables, but they are likely become UAC variables or they become environment variables depending on whatever they are needed for. When you do that, you can add a multitude of options to your script to also allow any universal task that you're gonna create somewhere or a script that you create somewhere to make that executable on the agent level by basically just making sure that you allow the command line to add this as options to whatever script you're gonna be executing here. And then there is no reason why anything of those functionality would actually require a controller or a universal AAC a UAC environment in completeness. So having said that, the other important part is you have a second option that is called the field definitions which is hardly visible over here. So, let's look at this into detail. So, in the template, you have the capability to define what kind of fields would you make available when a universal task is created. And basically in this UiPath sample, we require the process name. Of course, we need to tell the orchestrator which process is it that you have to execute, translating it to which robot is it that you have to execute, on which server instance do you have to execute that, what logical account name do you have to use for being able to do so, and where actually is your URL or what is your URL for connecting to the UiPaths environment in general. Also, what you see is you see different field types. In this case, it's all text fields and they all map to something within the template where you can specify the names or whatever. And you have a variety of different options. So basically, you have text and integer and boolean fields and scripts and arrays and whatever you wanna do with it. My favorite actually is the so called choice field because that gives us a capability depending on the input in a particular field to make other fields visible or hidden. So when you gonna specify a particular URL for example for the orchestrator of UiPath and that requires a specific credential to be entered, you can basically make credential field visible and as long as there's not that specific URL specified, then you just have that credential field hidden. And of course, you also can have these things read only. So that means they are protected and the end user cannot modify them anymore. You can have them visible or non visible or visible or hidden. You can have them as required field. So you can't save anything without having the definition made. You can have that as optional. So there's a variety and flexibility and capability of making those things exactly as you need them. And one of my favorite sentences for all these integrations that we provide, it's basically that your requirements or your business requirements basically define the scope of what you're gonna be providing here. The result, once you have done the template, once you have done you created the script and made it part of the template, Basically, the outcome is a universal task that is gonna show up for experienced UAC users. It's gonna show up on the left hand side in your navigation bar of the universal controller. And as you can see in the red marked area, that is basically exactly the definitions out of the template that you're gonna see here the process name, the instance name, the account name, and the URL. So it basically gathers into that universal task exactly the information that you require for controlling and managing your application in a proper way. So we can spend now more hours on doing that, but basically, that pretty much from my point of view describes the general concept of the orchestration and integration technologies. So basically, other key question is, where do I get that stuff? Well, there is a Stonebridge marketplace and as I say, currently under review where we're gonna gather all the universal tests, the connectors, any scripts and we've done a lot of examples for example for UDM or SAP type of scripts and examples or we're gonna provide complex solutions and that is a true open source approach. So that marketplace is open to anybody that is a StoneBranch user and you have easy access to it as part of the portal or experience center and you have the capability to download any of the solutions that we have provided and currently, that is definitely at no extra charge. You get the technology of part of your software licenses already. You get the solutions as part of the open source approach and that all without any additional cost at this point in time. That may change depending on the quality and complexity of solutions that we're gonna provide and deliver, but pretty much everything that you see on that famous circle on the left in the various areas as something that is gonna be available. And if it's not really already available on the marketplace, it's a simple email to your known StoneBranch contact and they will make it available and they will ensure that it's the right version and that you have the right documentation attached to it and everything else that you need. But with the latest release of Universal Automation Center, We also recognize that there is a different need and requirement expressed by the field and by the user community to have an ability to, let's say, install validated solutions through the product itself. So from that point of view, we've built a list load server operation into the six point eight point zero point zero release that became available in March of twenty twenty. And that contains a very selected number of universal tasks because there's two things that we, let's say, need to recognize and why we decided to do that very carefully. Number one is what ever you're gonna have available in this particular server operation is gonna be something that is maintained by Stonebench. So you have standard support contracts that include managing exactly those universal tasks that are shown here. One is the SSH task that is that allows communicating with a server that doesn't have an agent installed, and the other one is the UDN gateway task that has a multitude of functionalities for managing the gateway operation of our B2B file transfer component and really doing that as an integral part of our universal controller technology. Over time, there's gonna be more to come and they all have one thing in common. They're gonna be available through StoneBranch. They're gonna be supported by StoneBranch and they're gonna be enhanced and developed by StoneBranch. But at the same time, as I said originally, it's kind of an open source approach. You have the chance to easily copy that structure, the template, the script, the universal task, and then it becomes your code and you can do any kind of modification that you need to do. Maybe we are providing too much functionality for a particular client and he says, I just need this one function and this one feature. Fine. Get rid of all the others and just focus on that one particular feature and customize it exactly the way your business is gonna need it. But you're not gonna locked in to us as a vendor or to anybody else to make sure that we gonna provide the changes that your business is going to require. Everything can be done and it does require and I'm believing my technical context here, it does require a limited amount of capabilities in terms of scripting and handling that are not really IT specific capabilities. So a variety of options, a variety of solutions already available and I think the current count is something like sixty plus solutions are available through the marketplace and the marketplace is gonna be reviewed and over time, we're gonna identify what the most important solutions are for our customer base and then we will include those extensively into the embedded product capability of getting access to those solutions. Now, how does it all work in real life? Well, it's pretty simple. We have created a little, actually it's not a little, a workflow dealing with the process of providing data for an SAP driven billing process and we're basically making sure in the preparation for the job, we're making sure that we get all kinds of data created. We got a variety of checks available that allow us to validate before we're gonna do something, allows us to validate do we really have enough memory, do we really have enough resources available, and can actually do that particular file transfer to really make the data available in whatever format is required into whatever location is required. The second part of this workflow is basically the actual getting the job done. So we're gonna hold it here with a manual intervention and basically gonna say, Hey, can someone in the end user environment, the end user, the business department, the finance sector, whatever you want to call it, can somebody provide approval that what we have so far has been created correctly or whatever? And here, we're showing another integration scenario, but we're integrating that not via any alerting via email or in the product. So but we're integrating that via Slack as the communication platform. And you have the same integration available for Teams or to for any other communication platform. So then, we're gonna run a couple of SAP jobs that are collecting additional data and basically, at the the end of the SAP processing here, we're gonna either identify, hold it. We have a couple of billing data that we have that is not really well, it's connected to a particular client, but we can't find that client in our internal SAP databases. So then we're using the robot to basically say, okay, I have all the details as part of the initial dataset, but I will now start and adding the missing parts and pieces into the customer database of the SAP environment and we're gonna see how that robot is going to be performing and what the robot exactly is going to be doing. Once that is done, we're gonna do a variety of cleanups. We're gonna do some additional email communication back and forth to and that's more or less to show you the capabilities that the product has. So the bottom part is less of importance for the actual process, but it's more of importance from an illustration point of view. So all that said, let's go and switch to our actual product and you see the same workflow that you've seen on the last three slides. You're gonna see the same workflow here. And currently, it is just the instance has been created. So it's in the system. It's gonna be available for execution. As you see, they all have a status of waiting and we're just holding it up by having the initial step where everything else is dependent from having that put on hold for the time being. So we're gonna just issue a release command for getting that started and the first part is really gonna go really quick. And yes, of course, I mean we're not really creating some complex detailed data here, but we're somewhat faking the creation of data. And we see also and that allows me to illustrate another integration and I think Moritz last week has been spending an extensive amount of time on how that works. I just wanna show you that simplicity as part of a sample. We see that particular memory check here has failed and we wanna make sure that we're gonna look at the incidents within ServiceNow so we're gonna need to refresh our login here and we're gonna need to refresh our incidents list here and whoops, we're gonna see that on the third of June because that's the date of the repetition of the session that memory check has failed. We can look into the Intocin. So that's basically a classical ServiceNow ticket by now. It does have all kinds of information that we extracted available here. It does have in an attachment a file attached here that basically consolidates the output that this task created. So that's a beautiful one way authorization and that is basically just two additional commands that are delivered as action as part of the workflow. So, we can handle it this way and in that case, we know that the task is actually okay or we don't care and doesn't make any difference for the successful continuation of our work flow so we can basically say force finish it because force finishing is as you know a success status and then we're gonna continue. And as you can see, we are now ending up into an action required part of it and that enforces us and at some point, there would also be a little pop up window showing up here depending on your settings, but that enforces us to go into our Slack environment and you see it now is asking for the approval of the data. Of course, we have not, let's say, spent the effort of adding the dataset here or adding a link to the dataset here for showing where data is, what to approve. So we're just assuming he knows the end user knows what he's doing and we're just approving the data and giving that information basically back to our actual workflow and seeing that we now have a success and we're now in the middle of the SAP process that consolidates the data and merges the data with a variety, double checks that everything that we have in our input data is also going to be available within the SAP databases, and at the end of the day, we're going to come out with identifying a couple of, let's say, differences between the SAP internal information and the information that we are provisioning here. And once that workflow and that's basically a little additional SAP workflow that we're doing here and once we're gonna end with success, we can now say we now wanna release our robot and really wanna see what the robot is doing. Release this here and now we're gonna need to switch to a different server because the robot itself is running on another AWS server and here you see that the SAP GUI is gonna opening. It's gonna connect to the appropriate customer database, and it's gonna start adding in the goods recipient section. It's gonna adding a the users that were identified to be missing as part of the previous process steps. And actually, to remain with this example, we're only adding two users here in this particular session. So it's just for the demonstration purpose, but that was the biggest part because before we were even able in the very beginning, before we were even able to switch from one server to the other, the robot was long finished so we had to put in a couple of breaks to make sure that the user interface became visible and that you really can see what actually the robot is doing and this what we're doing here seems to be a very typical from all my readings and what I'm hearing from others seems to be a very typical robot scenario that is used in a multitude of places. And of course, the smarter robots get and basically now, that system has come to an end. It has done what it was supposed to be. It's now logging off of the SAP system and we can basically switch back to get to our workflow. And at some point in time, that UiPath step so to say or task is gonna come to an end, and it's hopefully gonna come to a successful end. And as it looked, it it will definitely be successful. It's now terminating the logon process and that sometimes just takes a while. So now we are at success. The one thing that I wanna show you here because the other things are not that much of relevant and we can just look at them after the fact is that you have in this part, you have available any output and I guess, no, I think, I know you can structure what exactly from output you're gonna need, but in this place, you have the output available and it basically says, okay. This SAP robot or this RPA process of create customer is in a status of running. And at that time, it came to a status of successful and the APR job has completed with a successful state and it has a start time and an end time. So the basic information of what happened within the robot, you can see it here so nobody needs to switch in any other tool into any other solution for getting the information. Now, we continue the workflow and basically there are two things that we have done here. So we have sent an email to for to a user and accidentally, I guess, I hope that's gonna be me that we're gonna send have been sending it to. Yes. And it says, you need to approve the billing data. So that's a second version or capability and basically we can reply to that email was approved and can send that email and then again it's gonna take a little while but at the end of the day, that job because here we have an email monitor that has a certain interval when he's gonna check the inbox. So it may take a sec a couple of seconds before he's really recognizing that the email has arrived and that makes it a dependency basically to say, here, we have a confirmation. We can make it a success which now has happened, and we can run the next job which is actually a scan data file. And that's an interesting thing. As you might have seen, I'm not changing anything on that particular job. It just went automatically to finish. So it was in an error because it has an error connection here. But with the assumption is that part of this sub workflow has fixed the error and we now can continue successfully with the workflow. The other interesting thing on that one is if we go back and look at our ServiceNow and we're gonna go back to our incident list. And we again have to, I guess no. Actually, it's there. So we have the scan data file that was the job. We have that marked and and a ticket opened as that was not successful as well. We believe that we internally fixed that error automatically. So we open a ticket for safety reasons basically or because somebody has to check after the fact. But in general, we don't hold up the workflow, but we automatically set it to finished because we continue the processing of the workflow. And that's basically where you can see everything has been done and that the workflow has been finished and we're gonna have some additional detailed information to be forwarded via email which basically say, okay, here is the reports for each individual step. When has it started? When has it ended? What is the duration time? It seems like that. So any kind of statistical information and where relevant, we might even have attached some of the output to it. So the other and you can look into it and you can ask questions at a later stage, but I guess it's not really important to show you other integrations because I think this is the major scenario that you're going to look in and that fully understands and underlines, so to say, what is it that we really are capable of doing with the integration for robotic process automation. You can have a hundred robots integrated somewhere into your workflow, open parenthesis. That probably does not make sense and is not really helpful from a visibility point of view, but generally, this is possible and you have the whole process built in an automated manner, but fully controlled basic in single place from a single GUI for a single user with the capabilities and you've seen some extensions or some X courses into the self-service implementation via ServiceNow. So, there's a couple of options that are coming up here. So what conclusions can we draw out of all this? Well, it's basically UHC has a perfect environment available for any kind of integrations or any kind of orchestration of workload processes by adding a variety of what we call best of breed solutions into a single integration platform. The integration platform itself is very flexible. It's very feature rich and will be continuously developed and enhanced. And I'm calling it agile because totally independent from the release cycle that we have or that you might have because for some reason, not all of our customers are upgrading in in in a speed where we're gonna say, okay, we made a new release available and now you're gonna need to upgrade. No. But we can deliver innovation based on the solutions that we can build by using the universal integration platform and that is permanently gonna be enhanced. And it's strategic initiative so to say because it fully supplies or complies to the beginning slide that I used or the CEO message given at the beginning of the whole online event and basically saying it's all gonna be focused into one platform and one solution for any kind of automation issues or environment. So if you look at it from a particular point of view, we have looked at workflow orchestration needs. So we have used various and a variety of best of breed solutions and applications. We have already seen certain things that are event driven and you have seen another presentation. You've seen more things. I think you're all aware and know a lot of the scheduling monitoring visibility and alerting capabilities. We've made a little X course into our self-service options capability. Yes, there's room for improvement definitely. But by providing or again, using the orchestration engine or platform here allows us to use certain standard self-service capabilities like we have available in ServiceNow and we have available in lot of other tools. We've looked or hopefully, we've looked at infrastructure management by given by by Alex earlier this month or last month showing infrastructure as code initiatives that we support and help to implement. And anybody who has ever been using our managed file transfer or cloud capabilities of provisioning data at a specific point in time into a specific place in a specific form, I think that we can do and automatically will do managing data pipelines is definitely something that we can do. So from that point of view, I appreciate your focus for this presentation. I hope the second presentation that we are now recording hasn't been any worse than the first one and I'm handing it with a strong thank you, especially a strong thank you to my colleague Ravi that listed down here who has provided a tremendous amount of support on making that workflow and making a variety of these integrations possible, workable, and even understandable for somebody less technical than me, and he has been a true and very, very important resource for making that work. So I say thank you for your patience, for your listening and apologies again for having to redo the session and the recording and I hand it back to Marissa. Marissa is going to work through some of the questions. Yes. Yes, I will. Thank you very much, Helmut, for going through that again. I think it just gets better every time. Okay so the questions that we received on Tuesday, the first one was, I keep wondering how do I get these tasks inserted into my UAC? Okay. Was it explicitly related because I just had an acoustic problem? Was it explicitly related to UiPath or to universal tasks in general? It just says these tasks, so I guess universal tasks in general. Okay. So here is what you can do and I have to go back a few slides. Do that again. So basically, if you see the above link, https marketplace at stonebranch dot com, you're gonna end up on a website with a list or a display or a graphic of showing all the universal tasks that are available in that marketplace. On the left hand side of that marketplace, you have a filter mechanism where you can filter out specifics that you use. Yep. I know the filter sometimes has its issues and but I'm sure that during the redesign or the review of the current marketplace, we're gonna hope that and you're gonna find the task that you are looking for and you're gonna have the capability of downloading that particular task. So, can select still. It moves you further down to the GitHub because everything that we do in terms of XML storage is gonna be done on the GitHub repository. And there, you can download the documentation. You can download the task. You can download the template or you can actually download the whole package. Right? So moving it further and going back to our famous controller, if it lets me move my mouse that way, and we're going back to the left hand navigation tree, and we're basically gonna look at all tasks. For example, we're gonna right click on the blue arrow here on the task name column, and we're gonna ask for import. And then basically, all we need to specify is we need to specify where did we download the marketplace task that we have selected, where have we downloaded those from, specify that pass, and it will automatically upload or import those downloaded task definitions into your controller environment. Now, once it has done that, one thing that you need to keep in mind, you might not immediately see the task showing up here because one of the things that you have to do and now I need to be concerned. I think we do it here. We have to refresh the navigation tree and then additional tasks that we have imported will show up in the area where they belong to. So let me just close down the task and let me open up the universal task bar here and you see that is a variety of the universal tasks that are available. So you have AWS native basically integrations. You have Azure integrations. You have a variety of Google cloud storage integrations. You have Hadoop integrations, HDFS, blah blah blah, whatever. So, this is the way you're gonna get it in. The other way of getting in a limited number of tasks that I mentioned, if you click on the administrative button, you're gonna see the server operations over here. You're gonna say list and download. It's not locks. List and download built in universal templates. You're gonna run this. You're gonna have a selection criteria where you can say what is it that you wanna import. So you're basically gonna click a particular well, he doesn't even allow me to click that button anymore because I already have those universal tasks, but usually that would bring a little button on the left hand side. You click that button and you're basically gonna say that you wanna load that particular task and then basically internally, the pretty similar or same process happens that we've just gone through and the tasks will become available in your navigation tree as available universal templates that you can start modifying, adopting, changing to whatever need. Yet, they are all the ones that we support. They're all gonna be initially read only. But we you can at any point in time create a copy of it. If you have or wanna modify it, then it becomes your task. It becomes your script. It becomes your code. It becomes your universal task. And you can do whatever modification or change that you want to do to it. I hope that clarified the question. I hope so too. I think probably it did. Let's see. And he had a follow-up. He just said, he tried to get the e c two tasks, but the search just returned s three. And I think the things that you just suggested will help that issue. Yeah. May be that the EC2 task because this is a native integration to an AWS services API for provisioning server systems. It is possible that that has not yet made it to the marketplace at all. I have no idea why instead it then collects the, what do you say, the AWS or the S3 storage task or whatever. That's something that I need to find out. But generally speaking, if you at any point in time connect your Stonebrench representative as far as you know who that is or you can simply contact myself or Marissa. We're gonna make sure that we're gonna send you a link to the proper version of the universal task or we send you the code of the universal task in case it hasn't yet really made it to the marketplace. Yeah, exactly. We have one more thing, not necessarily a question, but it was a nice comment. We had someone watching previously say, hi, thanks for the great presentation, it's really interesting. It has opened up a new integration scope in our environment, which is exactly what we wanted to do with this. Exactly. Exactly. Yeah. Very good. Like that comment very much. Yeah. Me too. And, we did have one last person ask marketplace was in maintenance. No, it's not necessarily in maintenance right now, but it's at the beginning of a big overhaul that we're going to be doing on it, which I think will improve usability quite a bit, and I think that'll benefit all Stonem Ranch users. So be on the lookout for more information about that in the coming months. Yeah. Okay. I think that was everything. Thank you very much once more to Helmut for redoing this presentation. I'm sure everyone who watches it will be very, grateful. A lot of people reached out and said that they watched the presentation with no audio because they thought it was so interesting, so I think this will be a nice surprise for them, and for all of you who stuck around for the presentation with no audio, we hope that this is even more helpful to you. Those of you who were able to hear, we thank you for coming, and all of you who are watching for the first time, thank you for watching. We really appreciate it and we look forward to hearing your thoughts. If you do have follow-up questions, please feel free to email me. You should have my email address from the initial email that I used to send this out, and I will make sure that your questions get sent to the right people.