So, here we have some other interesting use cases that are very useful for customers and that save them very I mean a lot of the effort and time. So, this solution is about the fast and secure patching of SAP landscapes. So what we have here is for customers that are using the cloud, so mostly Hyperscalers and that they can spin up and shut down servers as they want.

These use case what we'll enter is to create a copy of system of a productive system or a sandbox system or a development system of SAP that they already have. In order to try to test with it or apply SAP super packages on it, so that they can do their tests before doing all the patching chain. So, before starting the patching and development of sandbox they're moving it to quality and they're moving it to production. If they want first to make sure that the patches contain the features that they need to use. They can just spin up temporary system and do all the tests and then shut it down and decommission it and do all this patching in the real systems. So for this, the mechanism of the workflow it's quite similar to what we saw when we were deploying the SAP HANA database. So, we will just provision a new server on the cloud or if we're using any of the virtualization like REV or even VMware, we can do that and create and provision the virtual machine for that. Normally what we do in this solution we integrate it with Red Hat Satellite which is Red Hat's a life cycle management tool with which we can keep up to date all our servers and keep the same Patch level in all of them and we Patch all the servers with that. So we use satellite from Ansible, we trigger playbooks that will use satellite to patch the servers to the same level as the source servers that we are copying from. Then we will install SAP HANA whatever we have in in the source system and then we'll do a system copy a copy of the database from the source system to this new system that we have provisioned. We will patch it to the last level so to the same level as the source system is also at SAP level and then we will apply the SAP super packages for example that we want to try. It's important to note that this application of SAP super packages is not done automatically because it makes no sense as you know or some of you might know if you're acquainted with SAP. All the super packages when you install them you need to or the functional teams need to review all the objects that are being affected in the system in the SAP system by those patches. So, this goes back to the same question we presented or we introduced when we were having the overview of SAP.

This relates to the code custom code that customers develop in SAP. So since they, when they're developing their code, they're touching and modifying many of the standard objects of SAP. Whenever we are performing an upgrade we are applying super packages or whatever they need to check if these packages touch those objects that they have modified. So, there's a lot of manual interaction there, that's why it makes no sense to have a solution to apply automatically super packages. So this is the part of the solution that needs to be done manually but all the creation of the system or the virtual machine installation of satellites and the patching with satellite installation of the database and of the SAP application all that and the copy of the database is done with Ansible playbooks and automatically.

The tests can be also automated. We can define a test battery or a test set to try all these new functionalities that the super packages or whatever we've applied in our system will do and then yes we can define as we said an acceptance or approval change, a change sorry for this. So once all the tests have been conducted and the users don't need this system anymore, it can be decommissioned automatically also with Ansible and all the virtual machines can be destroyed, decommission etc resources will be freed and that's all done automatically.