Hello, everybody. My name is Nils Buer. I work as a director of product strategy at Stonebranch. Today, I would like to demonstrate you how webhook can be used to trigger automation task in Universal Automation Center. Before we start with the demo, I would like to give you a short overview on the advantages of using webhooks over classical API polling. In today's real time world, a process needs to be kicked off as soon as the data is available. This requirement is not only valid for business processes like a payment transaction, a financial dashboard refresh, or an SAP order process, but also for IT system notification and alarms in DevOps processes, when a developer example given commits new code changes. In most cases, time based processing does not meet the real time business need for those processes. The solution for real time processes was and is still in many cases based on polling or long polling, recall. When using polling, the frequency of your polls limits how up to date your event data is. For example, if your polling frequency is every twelve hours, the events returned by any poll could happen anytime in the past twelve hours. This means that anytime an event occurs in the endpoint, your app will be out of date until the next poll. Polling data is always old. It is the data that was correct at the time of your last poll. This means that every time an event occurs in the endpoint, your app will be out of date until the next poll. If multiple event occurs between two of your polls, you might even miss the data. With webhooks, this problem is eliminated since events are posted immediately to your monitored URL. Your apps will automatically update themselves with the new data almost instantly. Webhooks are far more efficient than polling from a resource and communication standpoint. Savior did a study across thirty million poll requests made through their services and found that ninety eight point five percent of polls are wasted. And they spend sixty six times more resources on polling. Data is always old. The very nature of webhooks and the fact that they are typically event triggered means that they are providing you with near real time information. Due to this, if you want information as close to real time as possible, webhooks are the best choice. Webhooks are superior to polling in terms of freshness of data, efficiency of communication, and infrastructure cost. There's, however, one main advantage of polling. That is you are completely in control of the amount of data you're getting. When using webhooks, it's necessary to have a good event filter mechanisms in place to only react on the events you are interested in. How are webhooks supported by Universal Automation Center? With Universal Automation Center, you can trigger a task or workflow based on any subscribed Webhook topic. When you receive the Webhook event, it is mapped to our internal event called universal event. The universal event can then be filtered and monitored using a universal monitor. Any information in the universal event is also available as variable for further processing. A universal monitor can then be assigned to a universal trigger, which permanently triggers an assigned task or workflow each time an event matches the universal monitor filter criteria. Okay. Let's switch to the demo. In the following demonstration, I will show you three examples how webhook triggered processing can be performed in Universal Automation Center. I will show a DevOps use case, where on each code commit, an email is triggered to the DevOps team. Then I will show how a cloud file transfer is triggered whenever a file is stored in a specific AWS bucket. And finally, I will demonstrate how to start an SAP process based on a received PayPal payment event. Okay. Let's start with the demo. In this first use case, I will show a DevOps case, where on each code commit, an email is triggered to the DevOps team. I'm now logging into the my GitHub job as code repository. I will switch to the development branch. Let me now show you the webhook configuration of the repository. This webhook will send any push events to the configured payload URL. This URL points to the universal controller PS1 to the configured endpoint githubwebhook. When the event is received by Universal Automation Center, it is converted into a universal event, which has been set up for the endpoint with the ending githubwebhook. I will now perform a code change, which should trigger the push webhook event. In the following script, the OS module is missing, so I will add the import OS command. I will add in the change node missing module OS edited and commit the change. This commit should have triggered a webhook event sent to the configured Configured Universal Automation Center endpoint. As you can see, the event has been posted. All event information like header and payload information should be available in Universal Automation Center for event filtering and further processing. Let me now switch to the Universal Controller to show you how the event is retrieved and further processed. In Universal Controller, we have configured for each webhook a universal event template. When a webhook sends a message to the endpoint defined in the template, in our case GitHub webhook, then the message mapped to an internal event called universal event. In the Attributes section, you can find which attributes from the incoming event should be mapped to the universal event. Example given, the entire payload, CXGitHub event attribute from the header, and a custom attribute landscape, which I set as additional parameter in the payload URL in GitHub. The occurrence of universal event can then be monitored using a universal monitor. The following universal monitor goes to success each time a GitHub push was received from the repository job as code, branch, development, and landscape stone branch. You can put the monitor in a workflow, or you can use a universal trigger, which automatically restart the monitor after it went to success. In our case, I use a universal trigger because I want to send an email to the development team each time a GitHub commit was done. Here you can see the universal monitor trigger. Each time the monitor gitub event monitor goes to success, the trigger launches the task gitub code commit. This task sends an email with all relevant information to the DevOps team. When I look at the activity monitor, then you see that the universal monitor for GitHub events is running. I will perform another code commit in GitHub so that you see that in real time, the universal trigger fires a task that sends the email about a new code commit. The trigger inherits all the information from the created universal event as system variables. These variables are also available in the email task, which are launched by the trigger. Let me edit the code again and perform another commit. Now we perform the commit As you can see the webhook event is received without any delay and the email task has been launched. When I list the variables, then you can find any information of the webhook events which we defined in the universal event template. Example given, you can find the entire payload in the variable trigger GitHub webhook payload. The variable content can then be parsed and printed out using our universal JSONPASS function. Let's have a look at the received email. In the email body, I print out all the relevant information of the GitHub event. You see the landscape, repository name, branch, push message, etcetera. This was a demo on how to subscribe and react on a received GitHub webhook event. Let me show you the next use case. In the next webhook demo, I will trigger a cloud file transfer whenever a file is uploaded to an s three bucket. Okay. Let me switch to my AWS console. I configured the s three bucket s b webhook test to send an AWS SNS notification to the configured endpoint in Universal Automation Center whenever a file is uploaded to the bucket. Here, you see the endpoint AWS SNS webhook configured in the universal event template in Universal Automation Center. Before I upload the file, I want to show the configuration in Universal Automation Center. You can see that we have a running workflow with a started universal monitor. This workflow streams a file from the s three bucket SP webhook test to an Azure Data Lake folder when a new file is uploaded to the s three bucket s p webhook test. At the end of the workflow, we list the Azure Data Lake folder to verify that the transfer was successful. Okay. Let me upload a file to the s three bucket. I will upload a local file from my laptop to the s three bucket. What you can see is that immediately after I upload the file to the s three bucket, the monitor has detected the incoming webhook event and goes to success. In the next step, the uploaded file is streamed from the s three bucket SP webhook test to an Azure data lake folder using our in the cloud data transfer task. Here in the task, you see the source system, which is r v s s three. You see the target system, which is as a data lake, and you see the file, which should be streamed from Azure from AWS to Azure, and you also see the credentials for the source and target connection. And when I go to the output, then you can see that the file has been successfully streamed from s three to Azure. Finally, I can check that the file has really arrived in the Azure Data Lake folder. You can see the file is available in the Azure Data Lake folder. Let me summarize what what has happened. The file uploaded to the s three bucket has triggered an AWS SNS notification, which was sent to the configured endpoint AWS SNS webhook defined in the universal event template. The monitor identified the new event and went to success. This was a demo on how to trigger a cloud file transfer whenever a file is uploaded to an s three bucket. I have prepared one more use case. In the last use case, I trigger an SAP workflow based on a received PayPal payment event. I use PayPal only as an example application. Most of the modern applications provide a webhook. Example given, we have one enterprise customer that downloads any new online signed contract from their digital document platform on the internet, each time the webhook event new contract is received by Universal Automation Center. Let me now switch to my PayPal payment platform. In my PayPal payment platform, I configured that each time a payment has been completed, a webhook event is sent to the configured endpoint, PayPal webhook, in Universal Automation Center. In Universal Automation Center, I configured a workflow which starts the invoicing process in SAP each time the payment event has been detected by the Universal Monitor configured for the PayPal event payment capture complete. Let me trigger a new payment in PayPal. You can see the PayPal event which is sent to Universal Automation Center, where it is converted into a universal event. Unfortunately, PayPal delays the sending of the webhook event when using the PayPal webhook sandbox, so we have to wait some seconds. Now the event has been received, and the process has been automatically started. The first SAP ABAP programs have already been executed. I will not wait until the invoicing process in SAP is finished as this takes several minutes. This use case showed that you can subscribe to any webhook event of a modern application and can start a workflow automatically whenever the subscribed event is received. This was my last use case. Let me summarize what you have seen. With Universal Automation Center, you can subscribe to any webhook. You can trigger any task or workflow in real time based on a subscribed webhook event. By triggering a task or workflow using a webhook event, you avoid resource intense polling. Any information in the received webhook event is available as variable for further processing in task or workflow in Universal Automation Center. I hope you enjoyed the video. Thanks a lot for watching.
