Conquer SAP testing challenges: 
How can we work smarter, not harder?

Welcome, everyone, to our webinar, conquer SAP testing challenges, how to work smarter, not harder. My name is Maria Robinson, and I'm the head of marketing here at EPU's Lab for Europe, e. So what's our agenda today? We are going to briefly go over some introductions to see who we have here today with us as speakers. And as well, I've seen some, new names in our audience. So we're gonna introduce a little bit of who is EPIS Labs and who is WorkSoft. And then we're gonna dive in directly into the solution demonstration of Certify from Worksoft, and we're gonna see how data sync manager integrates, with the solution. At the end of the webinar, we're going to have, some time for a q and a session. So please, feel free to, type any questions in the question box, at any point during the webinar. The lines will be muted, and this webinar is being recorded. So we are gonna be able to share it with you, after, the event. And when I say ask away, it's because today with us, we have, Paul Hammersley, the SM product manager, and Nick Yoanu, director of solutions engineer at Worksoft. And these two guys here can answer pretty much any question there is about DSM and Certify. So, this is a really good opportunity to listen in and see how these solutions work together and ask, any questions you might have. At ease labs, so who we are, our mission is to help clients transform, their SAP landscape and solve their business challenges. And to do that, we have a wide range of solutions and services that go from, reporting in HCM to sunsetting legacy data, and as you will see today, test data management. We're very proud of the ninety seven percent client renewal rate because it really shows the partnership that we build with our clients in order to help them solve whatever challenge they might have in their businesses. We have a multilingual in house global support that will be there twenty four hours every day of working week. We are a member of Group Elephants, and it's a group of companies that commits to donate one percent of their annual revenue into ERP, which is our nonprofit program to help population in Africa and also, animals at risk. Right. So, what I would like to do now is, ask a little question. So we had a first webinar where we had a conversation about the importance of testing and change management and how can businesses really become more agile as this is a very needed requirement nowadays. And we have a SAP insider study that we've been looking at quite a lot, but I would like to ask this question to the people here today, and see how, that compares to the results that we have. So I'm just gonna exit the presentation mode. One second so I can launch, the poll, and I really would like to see what people have to say here today. I'm just going to launch it now and give you a few seconds. So if you can please, tell us what what are your organization's challenges when it comes to testing and change management. I've given you there a few options that we think are the most common ones, and, yeah, then we can have a chat about their results. So we have a sixty percent in the lasing provisioning quality test data, and then we also have a lack of appropriate testing and change management tools, which is brilliant because that's what we're gonna cover here today. And, it's also, quite similar to what you can see on the screen right now. It's what SAP insider is telling us. I believe they interviewed around two hundred IT professionals around the world, and these are clearly the most common challenges out there. So as Nick and Paul were talking about it last time, there is a big element of cultural mind shift and awareness that needs to happen, and that's why probably there are problems in the planning and the road mapping, as well as the immature collaboration among teams. But then as well, there is a big element of the technology. So what tools can we use and the test data? So without further ado, I'm gonna hand over to Nick so he can tell us a little bit more about Worksoft, Worksoft and Certify. So yeah. Thank you very much, and I hope you enjoy. Please, remember to ask questions. And over to you, Nick. Thank you, Myra. If you would just flip through to the next slide for us. Alright. So hi, everybody. Just a quick hello from my side. Thanks for joining us in this webinar. Maybe a quick introduction to who Worksoft is. Always good to start there. We're a test automation company. We've had over twenty five years worth of experience helping organizations manage and thrive through change, whether it's large scale transformational change, through various projects, or day to day changes as part of business as usual. And we've had the pleasure of working with some of the largest, most complex, and even most innovative organizations in the world. So we consider ourselves to be incredibly fortunate, having been able to do so, but really helping them automate their testing across both packaged as well as custom built applications. Really, our specialty lies in being able to do that across end to end business processes Because we know that in any typical enterprise today, a process is not made up of just one application. There's usually a stream of applications that make up a business process. So what we do at Work Software in Testing, we're ensuring that changes to applications or workflows right across the board of thoroughly tested before they go live into production, ensuring that applications work together to support the business. So for us, it's more than just testing your applications. We're in the business of testing your business, and that's our mantra. Because at the end of the day, it's really about providing business process assurance. So, really, it's about helping support the delivery of change and transformation, but at the same time, helping and helping customers really elevate the quality of what they're releasing into production, helping them do it a lot faster, a lot safer, and helping them get through to the other side very successfully. Now even though today the focus is gonna be on SAP, and you can see some of the numbers there in terms of our experience, in SAP testing, and we're certainly the gold standard for that, for testing SAP, but we have a ton of experience, across other applications that make up an end to end process. I just wanted to get that out there again just in case we don't have time to look at that at the end of the webinar today. And we're very used to working in very large, complex distributed organizations, with a lot of experience across different sectors and different industries as well. So, Maria, if you can just flip through to the next one. Now I mentioned complexity and change. That is typically what you see in any organization today. I don't think that's news to anybody. Right? We know that organizations and businesses today are constantly evolving. They need to constantly adapt to changing markets and customer needs. So in order to do that, they're having to absorb and adapt and, adopt new technologies and deploy that into current landscapes, ensuring that they can actually do what they need to do to serve customers, partners, and suppliers effectively and efficiently. But as customers are doing this, they are having to adopt more complex technologies, managing and releasing these changes, across the enterprise. And this is becoming a lot more difficult. And there's a number of different reasons why this is actually complex for the typical organizations that we work with. And I suppose the first one to mention here is that there's techno technological complexity or technology complexity. If you think about the typical company today or organizations today in the enterprise sphere, These organizations are made up of a number of different technologies and different systems. Some might be on premise. Others might be in the cloud. These technologies have different user interfaces. Very typically, you find browser applications integrated with desktop apps. A lot of organizations, depending on the industry, are still running things like a mainframe. And then you've got the API layer that's integrating all these technologies and other back end infrastructure, databases, and so on. So there's so much complexity there that organizations have to manage today. And when deploying new technology into that, they not only have to ensure that the current technology stack is working, but that the new technology is gonna be able to work with whatever they have in place today. So it's really becoming harder to keep everything running smoothly. It's one of the current it's one of the challenges that we constantly hear about. As organizations are changing and adapting and having to release more, they are adopting other methodologies to be able to do that. So things like agile and dev ops have been with us for a number of years, and organizations are turning to that more and more to help speed up delivery. But with pressure to deliver quickly, sometimes quality does take a back seat. So to deliver faster, very often, shortcuts might be taken in order to get these new features released in time, and that can have an impact on quality and an impact on, just overall risk when it comes to, to any enterprise environment today. And then, of course, there's the people factor. We know that teams often spread across different locations. Sometimes they work in silos. So this takes a lot of coordination between business, the quality teams, and IT teams, which makes it a lot more difficult. So these are just some of the, some of the complexity that we see in a typical enterprise today. And managing all of this or trying to manage it without technology becomes almost impossible. But this is really where WorkSoft actually comes in and really where we shine as an organization in terms of the solutions that we help organizations with. Because what we're in the business of doing is helping organizations ensure that they can actually test end to end. Again, I mentioned that previously, but our focus is not just at the application layer or the application stack, but across the business process, across the entire plethora of applications and technologies that support the business process. And the way that we approach it, the way that we do it, the reason why customers come to us and stay with us is because we offer solutions that are really scalable. We've got a no code automation platform, that can pretty much automate any application that touches a Windows desktop. So whether it's in the cloud or on premise or a plethora of different combinations of those, we can support customers to automate testing across all of that. And our focus, of course, then is on reducing risks and cost associated to testing so that organizations can release a lot faster with a lot more confidence. We're also agile and DevOps friendly. So if you wanna actually increase the, the cadence for these that you might wanna actually move towards in the future, we can definitely help you with that as well. So this is really where we're strung out. We're gonna be taking a look at some of that into today's demo. And speaking of demo, let's maybe just go and take a look at what we're gonna be looking at. We've got a number of solutions. We bring them together into a framework that we call CAPTCHA, automate, and run, and it's very purposefully designed to remove bottlenecks that exist in typical testing methodologies and frameworks today. We start with CAPTCHA. It's a mechanism that we use to discover a business process. We discover how a user is doing their work through one or more applications. And that's really, really crucial because what we've seen is a lot of organizations struggle with what they need to test in the first place, and we make it a lot easier by giving them tool sets to extract user activity, which we can then convert into different formats, so things like process documentation. But then, ultimately, that feeds into the second part of the pillar, which is made up of our automation studio and other surrounding capabilities where we generate no code test automation assets, helping you build up your library of test automation assets very quickly, getting you to the point where you can then scale out your testing in that run phase in order to run any kind of enterprise testing, on a very regular basis with whatever load you might wanna throw against the system. So that's what we're gonna be looking at today. We're gonna be doing a bit of a live demo. We're gonna be using SAP, but, again, I wanna label the fact that we do a lot more than just SAP. So, Maria, if you can just give me a sharing rights, I'll take over. You should be able to see that there. Fantastic. Alright. So I mentioned that we've got a specific methodology and approach. We call that capture, automate, and run. So this is our capture tool. It's a mechanism that we put into the hands of literally any kind of user. The only requirement here is that the user that you give capture to should at least understand how an activity is executed through an application. So let me take on the role of a business user today. I'm somebody in the sales department. We're gonna go and create a sales order. All we ask a user to do is turn on CAPTCHA and then step through a process like they normally would as part of their day to day activity. So as a user, I'm just gonna go through the various screens that make up my process. I'm gonna interact with all the mandatory fields and just inputting data that might be necessary in order to fulfill this specific, transaction. So just moving from one screen through to the other. And because this is a sales order, there are some other things that we need to actually fill out. So things like sold to party and shipped to party. Let's go ahead and just complete that. Give us a customer reference. Let's say somebody's calling into buy some bike parts, in this instance, some bike mirrors. And because it's a sales order, we're gonna need a material. And let's specify an order quantity just to actually complete this out. So these are all mandatory fields. You can't actually save the sales order without specifying these things. So all the way through to the very end, we can then save the transaction. And as a user normally would, then they'd be looking for some feedback to let them know whether they're successful or not. So let's say we've done enough here. Let's stop CAPTURE and take a look at what's been happening. As we've been doing our work, CAPTURE has been looking over our shoulder. It's been understanding the sequence of steps that we've worked through, and you can see that it's actually generated an easy to understand narrative of each and every step. It's saving all the data, but it's also taking a snapshot of each and every step over here as within the script here as well. You've got some additional capabilities where you can come in and add some additional notes where you might be able to say things like, please save the sales order number as an example. So this becomes a great way of capturing additional information within the script that you're actually building out over here. So it's not just about the workflow, but you might have some additional information that you might wanna pass from one side of the business through to the other. Once the user is done with CAPTCHA, they can save this into a central library and then forget about it, and we can then start generating some outputs from that CAPTCHA. The first output that we generate is a business process document that can be exported in PDF and Word formats. So if we go into this over here, we can see that you can give this you can give some of your own branding to this, give it your own look and feel. But what's really more important is the content that gets generated in these documents here. All that information that we recorded and captured get exported into these documents automatically. We start with a visual activity flow, which breaks down the activity that a user went through. So you can see that visually described, and these process models can also be exported to other tool sets that support BPMN format. But you can see all of those steps with the narrative, the description of each and every step, the data that was used, and a snapshot of each and every step contained within this document. Even additional comments that the user might be using get saved within these documents here as well. So this becomes a great way of capturing business knowledge and then passing that knowledge on to other people who might actually need it. So, like, people in the testing team who might not have the business knowledge that they need, This becomes the documented test case that helps guide them through the rest of what needs to be tested. So that's one of the outputs for that kind of use case. But you can use it for training and enablement, creating user guides. You can use it for auditing compliance. So we capture, and then the first output we produce is this document. The next output that we produce is an automation asset that feeds through into our automation library. So this is our automation studio. This is where all those captures actually get stored. And in keeping with the story, somebody from the QA team, the testing team would log in here and pick up on those captures and then extend them. Or what they would then do is create some automation themselves by, again, using CAPTCHA as well as some other no code tools, to help them along their journey. But let's take a look at what we did in this demo. If we go into it, you'll recognize that it's exactly the same CAPTCHA. It's all of the steps that we did together within the demo when we were capturing the sales activity, and we even got that comment that was passed from the CAPTCHA to the documents to the automation asset that can help guide the automation team into what else should we be doing somewhere down the line as we are hardening and extending these scripts. What I wanna show you is that you do get working automation right from the get go here. So if we were to give this over through to the automation engine and we click run and hand off the keyboard, Worksoft is gonna take over shortly, and it's gonna run the test, in the same way that we actually captured it. So it's going there. It's clicked on the tile. It's inputting the data and then stepping through screen by screen. Now granted, this is still a raw automation asset. You still need to add some additional steps in there to make it more data driven. You might need to add additional steps to save data, to do validations. What I really wanna get, across to you, to the audience, even though you still need to do those things, you get working automation right off the bat very, very quickly. So using our no code approach, we help you build out that library of automation assets incredibly quickly, comparative to some other solutions that might be out on the market today. Now when you're automating your testing, it's really important that you get meaningful detailed information returned back that you can then analyze. So you're gonna be getting that back in a result viewer with a lot of high level information. But the further down your drill, this is where you start getting a lot more meaningful information at a step level. So a lot of detail here around what you're testing, how long did it take, did it pass or fail. If there was an error message, you would get a descriptive error message here helping you troubleshoot, and then you can see all the parameters and all the data that you were using. But then for additional evidence, additional troubleshooting, you can also take the test step image of each and every step here as well. All of this rich information passes up into some out of the box reporting capabilities, ensuring that you can report on this effectively and then distribute those reports out to whoever actually needs those reports at any point in time. So just to show you what it takes to extend this, I'll make one or two changes very, very quickly. So for time's sake, we can't do a deep dive today. But any change that you would make to the script would actually be done through the UI over here. So let's say maybe the first thing you wanna do is make this more data driven, because at the moment, we've got a lot of hard code hard coded static data. So if you were to go and run this test again, it's gonna use the same data over and over again. And that's really not what you wanna do when you're testing in an enterprise context because it's not just about the workflow, it's all about the data as well, that you've actually got the right combinations of data that goes with that workflow. So in order to make it more data driven, we would just select the steps that we wanna convert, and we go and create something called a layout and a record set. Think of a layout and a record set as a table of data that you are gonna be using going forward. And if we look at these four steps, you can see that we don't have that hard coded data anymore. We've now parameterized it, and we've created this table of data with that initial, row of data here as the first row. And we can then go and experiment that data within the UI. So if our data set is small, we can go and make some changes here. Let's say we've got different distribution channels and different divisions that we wanna test. And if we were to go and click run, it will automatically go and loop and run the test twice to go and test each data combination that we see here. But, of course, typically, our customers have a lot more data than that, so you've got the ability to import from different sources. You can go and import files from a Excel spreadsheet or connect to a database. The one that we are incredibly excited about, the mechanism that we're excited about is our ability to tap into API use's capabilities and go and get fresh data from APUs each and every time, which solves a lot of issues for the kinds of organizations that we actually deal with. And I know Paul is gonna be expanding on that in just a couple of minutes. So coming back to this, we made one change very quickly. Additional changes would be made by launching tools within the UI that we're looking at here. But going back to what I mentioned, it's completely codeless. There's no scripting, no programming required at all. And you might be thinking to yourself, well, Nick, can it really be that easy? I mean, can you do everything by using a codeless approach? Well, let me give you an indication very quickly in terms of who some of our customers are. We've got customers such as SAP. They're actually a customer of Worksoft. They use our technology to test their instances of SAP internally. But we've got customers such as Nestle, Google, Apple, Microsoft, incredibly large complex organizations using Worksoft to do testing across their packaged applications and across their ecosystems. So you can definitely do any testing using Worksoft to no code approach. Now I won't be able to go into this in too much detail, but you would end up building out a library of assets. These assets as well as the data, as well as all the objects that you're building are actually reusable assets that you can use at any stage. So very, very quickly, if you wanted to go and expand this, and maybe you wanted to go and create an end to end order to cash process, you don't actually have to go and script things from scratch. You can just go back into your library, select the assets, select the data, select the objects that you wanna reuse, and just drag and drop them in. So, for example, if you want to include other assets in here, so we might wanna do things like logging in and then logging out. We might wanna do things like outbound deliveries, all those kinds of things. It's just a matter of then just going and selecting the right assets that you're interested in, and you can very, very quickly build out these end to end processes without having to go and reinvent the wheel each and every time. So we've gone from capturing, generating assets, showing you a little bit about the automation studio, how that works, how some of the components come together. But once you've built out that library of automation, you don't wanna sit in front of a screen, clicking a green run button the whole time. What you wanna do is get to the stage where you've built out your library, and then you can execute that as often as you want and then run it at scale. And this is where we hit the run part of our methodology. So we've got an orchestration capability that gives you the ability to run hundreds, thousands, even tens of thousands of scripts in parallel in order to get through any kind of enterprise load that you might need to actually test. So CTM works by creating what we call suites, and I've got a couple of these suites here. Think of a suite as a container of processes that you're gonna be running. So you would build out all of those scripts in the Automation Studio and then select them here within CTM. And then you've got the ability to really control this execution. So there's a lot of different parameters that you can actually specify, giving you very granular control of how these tests actually execute. The one thing I wanna point out over here is our parallel execution capability. You've got the ability to run tests in parallel, but you've also got the ability to do that completely hands off without human involvement, meaning that you can free up people's time so they can focus on other higher value added activities. So you can schedule these tests to run and then automatically send out email notifications to parties who then need to pick up on the evidence and the reports and then go analyze all that information. So even though typically you would be scheduling this or you would be hooking this up to a CICD pipeline or something along those lines, you can actually run it ad hoc, which is what I'm gonna do here in the final part of my demo today. So if we go into executions, you can see that we've got something running, and we could stare at the screen all day. We're not gonna see anything execute on my machine, but that's because we've got agents out in the environment that connect to the orchestrator. So the orchestrator will spin up those agents, will wake them up, will log into them, and will then start running the different workloads on these machines. What I wanna point out here is that parallel execution bit because we've got two different processes, but they're all running on one machine over here. So you can see on this one machine, we've started up two different, processes. One is an SAP GUI test, and in the other session, we're starting up a Salesforce test. So pretty much going back to what I was referring to previously, our ability to execute volumes of tests and then spreading that out across one or more machines, allowing you to run any kind of enterprise load in whatever time you might have available to you. So this will run, and then as these tests complete, the status will then come back into CTN, giving the ability to then do some, very detailed, analysis against those results and then going back to being able to report and dashboard on them as well. I wanna round off, my part of today's discussion to go back to some of what I alluded to previously. Even though the discussion was primarily centered around SAP today, in our last twenty five years worth of experience, we've automated literally hundreds, if not thousands, of different applications across different technology types. So whether it's browser based applications, mainframe emulators, or desktop applications written in Java, dot net, and others, we've got interfaces for all of those kinds of technologies. So the way I normally describe it is we can test literally almost anything that touches a Windows desktop. And then I know I might be laboring the point, but our strength here is in true end to end business process testing because there isn't an enterprise out in the world today that has a true end to end process that starts and just stops in one application. There's normally a lot of other applications, that, support a business process, and we can do true end to end business process testing across interfaces, doing validations, and passing data back and forth between them. Alright. So, Paul, I think I've come to the end of mine in terms of the time that we've got available to us today. Let me maybe hand over to you, and we can pretty much, carry on from there. Fantastic. Thank you, Nick. I'm just getting up the slides to pick up from where we'd got to. K. Nick, can you just confirm you can hear me okay, or Maria? Yes. We can hear you. Fantastic. Just loading right now. It is. Slight bandwidth challenge, Hopefully, any second it's gonna come up. So, while it's loading, I'll start to talk. And then if this isn't successful, we might need to share your screen. Sure. Okay. So, obviously when running any type of test, there is the process and what we've seen there is incredibly powerful in terms of that process. But what we also need to then consider is the quality of the data. Sorry. We're struggling with the screen again. There we go. Can you see the data sync manager suite? Yep. Fantastic. Thank you. So, obviously, the quality of the data is gonna be critical to the process. And so this is where the partnership of having the, fantastic test automation of the process, being able to capture it, document it, and then run it at scale, integrates incredibly well with the provisioning of test data manager and actually automates the two together. So using data sync manager to be able to make sure the data is correct, and is going to be an effective test. So you might have a system where you're running the testing and changes are coming through. It could be business as usual or it could be a particular project, and you want to make sure that the data that is in that particular, system is a match for what's in production. Because when that configuration goes through to production and that same sales order process happens and that customer is ordering their bike mirrors, we want to know that the project's changes or the BAU changes aren't going to, stop that process from happening. And you may even want to look at what's the outcome of that process. You might want to compare what's the final, pounds or euros amount on that order in production compared to what it is in the test system. So there's a couple of ways, that data sync manager can help. It has a few different components that we're looking at here, but I'm gonna talk us through each of these components and how they work. So the diagram that we've got on the left hand side is our representation of an SAP system. The gray part at the bottom is the base, so the system, repository where all the, custom programs might be stored and custom tables and so on. You then have the red layer, which is your client and customizing. The light blue is your master data, and then the dark blue, the larger part, is your transactional data. So the first component that we can leverage here is object sync, which is often referred to as data on demand. So you imagine we're running that test, but perhaps in our test layout, we started to vary the sales organizations. We want to be selling, our bike mirrors through multiple different organizations, but potentially one of those is a new sales organization. Has the material been extended for that sales organization? Maybe not. So the test could fail simply because your data is not actually the same as the data in production. In production, that work has gone through, and you need to make sure you can actually test for the configuration. Object sync allows you to bring that data down. So you could bring the material and update it completely with the latest information from production, or it could be unique condition records to know the pricing. So how that, particular set of bike mirrors will be priced depends on which sales org it's running in and so on, and there's a date validity on those condition records. Object sync could actually bring down the latest condition record. So particularly if you want to see, do this does the end value match what we're seeing in production, you would want to make sure those condition records are a perfect match. What's really, impressive about this integration is we can automate that step. So either using Worksoft to actually go and essentially use object sync. So before it starts triggering that sales order process, it goes and gets the latest version of the material or gets the, condition records and sends them into our testing system. And only when they've been copied does it then start running that process. Or alternatively, we can integrate to the APIs that we have for, some of the DSM components as part of the certified process as well. So we simply have steps that will call the API that sends the materials or condition records across, and then, again, the test automation can run. The next component is very similar to object sync, and it's taking the data, which could be for master data or could be the transactional information that's happened in the production system and bringing that out into a particular, format, which could be something like CSV. And with the extractor, we can specify the exact, ordering of the fields that we wish to get. So we can match the layout that you had for the WorkSoft certified process and feed data with the Object Extractor directly into those test, record sets. So the layout is a match, and the data can go straight in. So what this allows you to do is actually automate the, taking of data from production to see what's happening for this particular process in production and running it in the testing environment. And we can take transactional flows. So we could take something that's been an order, go to a delivery on through to a billing document. We can take all of that information to be able to automate that end to end process. We then have, a more proactive approach to the data. So with client sync, you can build a test client that will function like production, has all the same customizing, has all the same master data. You could have some transactional history, but you may not want any. You might even use the option within client sync to say, just give me master data and customizing. I don't need transactions because I'm actually going to create the transactions using the automation with Worksoft. So that's a really powerful option if you think about having a dedicated testing client that just has master data in customizing, maybe even limited to a particular company code or set of company codes as well. And just resetting it maybe every week or even every month would, be sufficient. And having these automated tests running and using Certify to look at the outcome of those tests and maybe compare the outcome of those tests with what's actually happened in production. And, of course, you can't ignore the privacy aspect. If you're using real data to do your testing, there could be information on that customer that's actually sensitive. So you can leverage DataSecure either in place in an existing test automation system or as part of object sync or client sync or even object extractor. You can integrate to the data secure policy and anonymize the data that's being bought from the production system. And then finally, shell sync or system builder for older versions of SAP allows you to set up the shell of the system to make sure the custom programs, custom tables actually match what you have in production. Okay. I'm gonna stop at that point and, open up the floor for questions. Thank you, Paul. Right. So we've got a few questions. I think, well, one of the most common ones that I see repeated a couple of times, it's within s four. How does WorkSoft work in s four? Seeing that eighty percent of it is standard. So how many test cases for customized s four roughly you think you can, use when using Worksoft to test and automate? It's very I think it's a bit of a difficult one to answer because customers differ. I mean, if you go from one customer to the other, they've got different processes. They've got different customizations. They integrate their SAP ecosystem with other third party applications. So I don't think there's a hard and fast rule to it. I'm gonna answer the question in another way. We're in the process of taking SAP's best practice library and converting that into Work soft automation. What that actually means is that we can provide accelerators to customers who need them, and then customers can then choose and select which of those processes might make sense for them and then adapt them to their own needs. So that's one way that we're addressing that. Okay. I think this one is for Paul. If you can describe how epi how DSM integrates with Worksoft, I guess, the back end a little bit. Yeah. So it's actually part of that process. So what we saw there when Certify was running through and following what Nick had set up in CAPTCHA was essentially what someone could do, themselves on a system. So we can add into to those steps specific steps for data sync managers. So we can, call object sync, and we can read information from the test layout in order to feed object sync to copy the data across. So in your test, record set, you might have, different customers, different materials, and so on. You could, as you're running through the tests, take the values from that record set and then either by automating the screens, because you can have the screen automation blocks carrying out activities as if they are users using DSM, or via our API. You can actually send off the request. These are the customers or materials that we want to send. This is the target destination, and away it goes. And that could even include the anonymization of data. So that part is nicely built in. You could also use the object extractor to go select the data. So I like the idea of having, maybe every night or every week, the selection of data from the production system. Go find all of the orders that were created on a particular date and send me the data from them as a CSV file that matches the layout that I need for the Worksoft, automation. And then it can go and it can run all of those, all of those orders in parallel and even look at the output. So what you can do with, with Certify with those process steps is look at the output, see what's happened in the system, what was the value, and then make rules to say what should happen. If there's a difference, if it's out by a percentage or whatever it may be, and then have actions that come off the back of that. Brilliant. Thank you. And I think we have time for one more question. Our challenges with test automation have mostly been with updating the transactional data for each new run. For example, we constantly needed to update posting dates and check material availability. How does WorkSoft cope with that? This is the beauty of the WorkSoft and APUs partnership. So the kind of the scenario that you just mentioned there is a very typical one that we hear about a lot when we've been speaking to customers in the past. That is what Worksoft and APUs actually solve together. So Worksoft is the automation engine, which needs to get its data from somewhere. APUs is the mechanism that provides the right data at the right time every time. So using its rule based templated approach, we can connect object extractor and go and synchronize data from production to QA and then transfer the correct transactional data that might be required, into Worksoft to then go and run the scripts. So we solve for those issues very intelligently through this partnership. So I think to add to that, Nick, you know, the example in test systems is a common one. The posting periods aren't open. So you try and run something and, yeah, I need to open the posting periods. You can capture that as well. So you could be going into the test system, automating going into the test system, checking the posting periods have been moved, on and are current and if they're not moving them on. And so that could be part of your automation. And then in terms of, you know, preparation transactions, we actually need to test something that is multiple steps down the line. You could trigger object sync to go create the first part of that transactional flow. So object sync could take a, transfer order and find all of the preceding transactions, update the relevant master data for you in the test system, and then start to create this process. Creates the order, creates the delivery. It gets issued, transfer order, and then here is your new document number. And so that if I can receive that new document number and then take over and go into Fiori or whatever it may be to do the next step and actually go through and create the, billing document or whatever it may be. Yeah. So it's really allowing to automate things that somebody would have to do or to automate checking will someone have to do something. Yeah. I think that's really important as well from a CICD DevOps perspective in order to be able to shift your testing left. If a developer wants to just go and test an invoice, they don't have to go and execute the entire process to get to that stage. App use can do all of that work. And then to your point, we can then pick up from the Microsoft side to just go and test the, the invoice. So making it a lot more dynamic, more efficient, and a lot faster. Or even clone that process. So you could start from one transactional flow and create six different copies of it and then test that step with six different outcomes. What will happen if someone does this through Fiori? What would happen if someone does this through the SAP GUI? Or, is there a choice in how we do this next step? We want to run four different options and see that each of those options work or even look at the output. What happens if it goes down this particular, track? Yep. Absolutely. Excellent. Alright. Thank you, guys. We've overrun for a cup by a couple of minutes, which is no no problem. But, Paul, if you can go to the next slide, I think next week, we're gonna have our last webinar of the series. So the last piece of the puzzle, transport management, change management, and we're gonna be talking about that with our colleagues at RedTrack. Thank you very much for your time today. Thank you, Paul, and thank you, Nick. We will share the recording of this webinar, shortly, tomorrow, or early next week so you can share it with your colleagues. And, yeah, thank you very much. Have a lovely day.