Introduction to SAP Process Orchestration

Hello and welcome to podcast.com. This topic is all about getting started to learn and understand about what is SAP process orchestration. Well this topic is like welcome to SAP world. You might be learning this course with previous understanding of Pi or C or with another integration tool background or this might be your first introduction to SAP integration tool wherever you are. But I assume that you are a newbie and first time trying to understand SAP process orchestration. So I will arrange the topic from very basic theory. We have taken previous courses like XML, XSD, XPath, Http Soap, ESB web Service, Soap, Wsdl, EDI, Pip, SAP, Netweaver and all the other basics that we have been learning through in previous topics. Then learning SAP is like super easy for you. I will be referring this keywords with understanding that you know these terms very well. Well, I will start this topic with basics like why there is need for integration tool and how SAP integration tool are used to solve integration challenges. This section will make you familiar with what is SAPO and its background. In future lessons, we will learn more about architecture than the actual tools. Well, let me give you a quick definition of what is SAPO process? Orchestration or PO is a combo product provided by SAP and is actually a part of Netweaver family. The primary purpose of this tool is to serve the integration needs, and SAPO is a product like Microsoft Office. So remember, it is a product. Each tool in SAPO helps to address the specific needs of integration. And when we say a CPU is a product, it's a combination of three different tools, like it has process integration, which is termed as Pi and business process management, which is S-bpm and Business Rules management, which is BRM. So if you're thinking what is SAP Pi, then you need to understand that POA is a product. Pi is the actual tool. And similarly, BPM and BRM is again a tool that is been available for us to work. And we will cover everything under a CPU. But in this section it is just the basics and the introduction. So let me give you the flow of the topic that you're going to learn in this section. First, we'll try to understand why there is actually need for an integration tool. What are the challenges in the integration? Then we'll learn about SAP process orchestration. I'll give you some background about previous releases of SAP and how it evolved till date, So you will try to understand what it is previously called as also we'll look at components of SAP. Finally, we will look at how SAP is positioned in the overall integration architecture. I'm really super excited to start the journey of SAP with you, so let's get started. Let's first understand what is the need for integration tools and how they are evolved. Imagine a business process of you interested to buy an iPhone. First, you will login into an, let's say, Apple site and place the order. Apple will receive the order and then it will place the parts order from its supplier to make that iPhone for you. Then once the parts are arrived, Apple Company will build the phone. Finally, when the phone is ready, it is shipped to you. Well, I've explained the whole process in a simple words, but actually it's much more complex than we defined. But let's observe the business process and the systems involved. Well, ERP application can be used to store the order shop floor and production floor might use a custom software to run the production line. The logistics system will make sure the delivery is done. Well, if you remember the topic that we discussed on EDI and Pip, those were the data standards that can be used to exchange the business. Communication between the trading partners like Apple might be using or Pip to exchange the communication between its supplier. So just to build one iPhone, there might be many data exchanges to happen between the systems. So the need of integration is really important to make sure that business transactions are exchanged between one system to another and just to complete one business process end to end. Also, each system might need a different type of data type or a different connectivity to exchange the message. So the job of conversion of data connecting two systems and routing of messages is typically handled by the integration tool. Let me now give you another view from an SOA point of view. Companies that follows SWA based architecture where all their business processes are split into services. Now, just to complete one business process, all the services need to talk to each other, right? And without the integration tool, all the services will start integrating with each other and thus it will complicate the entire landscape and will be difficult to sustain, obviously, in a longer run. Right. This does not mean SWA is a wrong concept, so should not be implemented. Don't have that assumption. Okay. But understand that does not speak about integration. It just says that when a company business process is split into loosely coupled services, then we say it's a IT architecture built on a or service oriented architecture or service based architecture. Well, with the Enterprise Service Bus or ESB, we can solve the integration challenges and simplify the integration. Architecture. Enterprise Service Bus or ESB helps to integrate all services and provide an integration platform to communicate. In the previous diagram, all we need to solve the complexity was a single point of integration that actually can remove the dependency from each of the service to connect and to reuse. It's like asking all the services to come to ESB, and then ESB will decide what to do next with that request. This helps the company because now they can understand what is happening in the real time and how business process are exchanging the messages. ESB is like single point of integration and it removes the point to point connection between the services. It's like acting like a mediator between two services to talk to each other. So by now, you know, SB helps to integrate all the services together. We have actually discussed this topic previously and we have also discussed the SB core principles in previous lessons. I'll just give you a brief summary. SB Architecture has the following principles that we discussed, right? So any tool in the market who says is an SB tool will follow these principles, and Pippo is not the only tool. There are many other tools in the market, but for now, let me give you a brief summary of SB principles. First, let's talk about orchestration. Well, orchestration means the tool should have the ability to connect to the system and exchange the message. Transformation means convert the data from one format to another format. Transportation actually means ability to connect system with different protocols like Http, soap, FTP, DB and others. Security means the message should be transferred in secured manner and no one should able to sniff or hack the message packets. Governance means able to govern the entire business process. Like we should have a monitoring tool. Restart stopping capability logs, audit maintenance, complete life cycle of the application should be available. The business process. Management means ability to define business process and connect systems so service won't talk to each other directly. They should use ESB to talk to each other and execute the business process well. These are the principles that Integration Tool or ESB Tools has to follow. Let's look at the entire end to end integration diagram with Purple. Well, pi or PO is an ESP tool, which means Pi or PIO supports all the above core principles that we just discussed. So Pi or PIO has this ability to connect to any system using different connectivity types like FTP, Http, soap, Jdbc and many others. It can convert data from one format to another format like CSV to XML and many others. It can transport data in a secure manner using certificates or in encrypted format. It provides the monitoring tools, deployment and entire application lifecycle tools to manage the integration. Also, it has the capability to run the business process. I know you might be confused. What is the difference between pi and pi? And I keep saying pi or PIO. Well, let's deep dive into what is pi and what is pi and understand where it belongs in the Netweaver family. You might have seen this sap netweaver diagram previously in the SAP Netweaver topic. Just to do a recap. SAP Netweaver is a technology platform that combines many tools and applications together, which actually forms an ecosystem and it solves challenges around people, process and information. Well, that's what we learned, right? So pi or PO will fall under the process section of the SAP Netweaver family PO, as I described previously, stands for Process orchestration and Pi stands for Process Integration. PO is a product and it's a combination of Pi BPM and BRM. That's why PO is called as a combo product, right? And it has many tools in it. And Pi is the integration tool or the ESB tool, which actually has collection of many tools inside to build the interface, monitor the interface and run the interfaces. So when you say, you know, SAP, you actually means, you know, Pi and even the BPM, including the BRM Well, in terms of deployment of the SAP PO So when someone say SAP runs on Netweaver, right? SAP uses Java only server from the underlying SAP as application server to run, and it can be configured to use many database like Maxdb, Oracle and etcetera. Let's try to understand in detail about SAP. So here in this diagram, I'm showing you how the sap is described. I know there is a new word ex, which stands for Advanced Adapter Engine. Extended ex is a new term being used instead of Pi because of its history. First SAP integration tool was called as ex I, then they renamed it to Pi and after that SAP started adding new features like Advanced Adapter Engine, which was a E, and then it improved that E to a ex. Now at this stage, pi and ex is actually the same thing. The major difference between pi and X is that pi can be installed on Java plus Abap, but x is only Java only installation. So when someone says a x box, then it actually means it's a Java only box. So using a x instead of pi help us to explain things in the right way. We'll always be confused when we refer to pi because we don't know Pi as Abap plus Java or pi as Java only, but with x now we can differentiate pi as Java only. Well, I have a separate section to talk about pi versus PIO. That's a complete topic just to talk about what are the internal architecture, how it is being deployed and why there is a difference between Pi versus PIO. So for now, let's keep the definition of SAPO as simple as Pi plus BPM plus BPM. Also, remember, whenever in the lesson, when I say a x, it is just Java only installation and SAPO also completely a Java only installation. Next, let's talk about each of these components and then understand its benefit. Like what is a X and its benefits? What is BPM and its benefits? And then what is BRM? You can now visualize the as the ESP tool, which actually helps to integrate all the application services together. And I will have some tools and components in it and then we'll go through that in the later section. But understand that will help to connect systems and act as an integration tool. Also does not have the BPM capabilities. It is the BPM component that has the BPM capabilities. Well, let me ask you this. Can you define or explain what is it called as SAP process orchestration? Why it is called as orchestration? What is the real meaning behind it? Well, let me try to explain it in a very simple terms. Well, if you really know the answers, like why the process orchestration is used for this integration tool, then hit the comment section and share your definition. Well, let me give you a simple definition that you can remember and use it anywhere. Well, I have shared this slide in the previous section during the lesson. Let me do a recap. Orchestra means group of musicians playing different instruments. Orchestration in general, English means arranging two or more things together to achieve a desired results. Well, in the context of service, arranging two or more services together to achieve a desired result is called as service orchestration. And in the context of ESB service, orchestration is a process of integrating two or more services together to automate a business process. And now the SAP process orchestration helps to combine all the subprocesses together to fulfill a business process. So PO actually has this as an ESB and BPM to run the business process together is called as process orchestration. Simple enough. Let me now go through the history of SAP Po. I'll quickly give you a very high level perspective from where the pie started. So you know the terms that was used previously. Well, I'm not so particular about the dates and the features. You know, it's added. That is a different section to it. But but I want to focus on what are the version numbers and what it is called as just to help you understand the terms that was used previously. The number one, two, three I'm listing out here. One means let's look at the version of pie and the two will talk about version of Bpmn and BRM and three will talk about the process orchestration version. Okay. Which actually a combination of A with Bpmn. So first let's look at pie evolution and history. This is the complete history of pie and and its previous releases. And I want to show you the names like Z Pie and X, which is now so you can see the different version numbers and the year and actually the tool name first it was called as Z, then it is called as pie, somewhere around 2005 and then now it is called as X. Next is the composite environment. Well, we haven't talked about C as of now. Right. Well, just to understand this new word composite environment is actually an environment provided by SAP Netweaver to develop bpmn and other stuff. Well, remember that Bpmn in previous version like x, I and pie was called as Bpmn, which were Abap based and did not use C at all. It was just an built in workflow feature of x, I and pi mostly on the Abap stack and understand that x i and pie was developed using Abap and Java. So CBM was using Abap Server to run the business process and it was very integrated inside the Pi tool itself. Well with PO or when the X was released, Abap was completely removed from its internal architecture. So even when Abap was removed, the BPM was also moved from the Abap stack and then it was moved to a Java stack, which was called as BPM. And this BPM completely run on this composite environment which actually runs on Java engine. But you know, composite environment is generally used to develop and deploy the BPMs. That is the reason in context of BPM composite environment was available from 2007. It's just that it was used by Pi, which were Java only installation. Also understand that soon SAP will go away from this dual stack to single stack to support many cool features like cloud integration. So it is important for you to get familiar with composite environment rather than CBM. Next is the overview of SAP, evolution and history. You can see the support of C and Pi together. That's where the Pi has a capability to deploy on Java only installation. So once the Pi has this capability of Java only installation, it didn't have the CBM at all and that's when the C came in picture and helped and provide this BPM feature to Pi. And now with SAP it see Java complete Java only installation. That's why it's officially said that Poe is a combination of Pi plus BPM and plus BRM and then BPM and BRM runs and develop using this composite environment. Now let's look at the duties of all the three components like what are the benefits and what does it help to do like a BPM and BRM just to make sure you completely understand this components. This is the diagram that actually shows the system that are used in the enterprise company. They will have like CRM, Portal, DB, HR, finance and many other systems in their landscape. And without the ESB, they make a point to point connection and make the integration very, very complex. Well, we understood that a X can help to integrate all the systems and exchange the messages. X plays the role of a middleman courier and a translator. Now let's look at the duties of X. Well, a X helps to route the messages to desired system 1 to 1, one to many, or many to one. It helps to transform or convert the data from one format to another format. It also provide secure transaction between two systems. It has the ability to talk to provider or consumer in the language of protocol. Well, also the monitoring tools are provided to do an end to end monitoring for audit purposes. It also maintain the version of the code and provide easy to develop environment. That's basically the duties of X. Let's now understand the bpmn. Let's look at how BPM are used. BPM stands for Business Process Management. This is an example of business process used to approve a travel budget. The business process is started when the requester submit a request for travel approval via Let's imagine it's an SAP portal. The portal can send message to X and then x can calculate the price. Then based on the amount. If the amount is greater than 5000, it can send an email to the manager to approve the request. Or if the amount is less than 5000, it can send a signal back to SAP portal stating that request is auto approved. The process is completed when approval is sent back to SAP portal. Well, if you observed the process as steps and each steps has to perform some kind of operation. So you need to organize all the steps in a sequence so that a business process is completed. Well, BPM actually are used to lay out all the steps in a sequence and execute in the same order. And BPM still uses the for connectivity and routing. Purpose and BPM are just used to execute the steps in sequence. Let's now look at the benefits of the BPM. Well, BPM supports human centric and system centric processes, which means BPM can wait and take inputs from human to proceed further or automatically decide the next course of action in the process. Now with BPM, we can see what happened with the request end to end as one process. Well being A and BPM separated means can handle the connectivity and routing and BPM handling the business process we can quickly adopt to business changes. Right? We can also monitor from when the message received till what response is sent back, including what are the business steps executed in one dashboard. That's basically the end to end process monitoring. Let's now look at BRM, which stands for Business Rules Management. BRM Are rules? Yes, business rules that we can define outside the BPM. So when you have a business rule that can change any time those rules we now need to define or hardcode inside the BPM. With BRM, we can define these rules and then BPM can use it during the process execution. So if the rules are not matched, then BPM will adopt to the changes accordingly, like the travel approval request process. Just we have seen BPM can have the entire business process and now the BRM can have only the rules of amount limit. That requires manager approval. In the diagram I have highlighted with yellow box, it is the rule which can be defined in BRM and it can be changed any time without doing anything inside the BPM. This is so powerful, right? So when a company decide the manager approval is required for amount less than 2000 or maybe say greater than five 7000, then it's super easy to adopt. This business changes. All we have to do is just to change the BRM and the BPM will actually accepts it. Right. So let's look at the benefits of the BRM. Well, BRM helps to separate the logic and the data, the logic in BPM and the rule in the BRM. It actually provides a central repository for all the business rules, right? It can change by business themselves based on the company's direction, and organizations are enabled to automate the business decisions, which means organization can now make the decisions of changing the business rules by themselves. Well, all the changes that we are doing in the BRM are basically real time and no update to the BPM required or no redeployment of the BPM required. Super cool. Right. Hope you have got a fair idea on what is a BPM and BRM and its usages. Let us go through the last topic on the positioning of. You need to understand where PIO is positioned in the entire system architecture. Well, there are generally three layers in the system architecture diagrams. The top layer is the presentation layer. The middle layer is the upper layer, which is the integration layer. And the third layer is the application layer on which the third party or the backend systems are available and the service are enabled in those systems. Let's understand each of its layer. The presentation layer is nothing but the medium through which the user can communicate, like mobile system or in a browser. It can also be called as an UI layer, also using which the user communicates. And PO is the integration layer, which helps to transfer the data from presentation layer to service enabled applications, which is the backend layer. PO provides the tools using which two layers can interact with each other and PO we have seen has to run business processes. BRM For rules management and for integration like connectivity and routing and the services that is being developed in Pi or PO can be maintained, discovered and managed in the Enterprise service repository. I know we haven't discussed about Enterprise service repository, but if you refer to the Wsdl section or the lesson we have talked about Uddi. So Enterprise service repository is nothing but the and these services can be published, searched and discovered by using what can be seen as an Yellow Pages for services, the service registry. Right. And all the services in the service registry can be exposed via the Pi layer. So the presentation layer can call the services in the Pi layer, but in turns it depends on the backend system to complete the service. Because the actual implementation of the service is in the backend system, pi layer is just an abstract layer service to the backend services. You can think it like a medium to transfer or call the service from the Pi layer or from the integration layer. The bottom layer is a service enabled layer in which the services are enabled in the application which can be used to complete a job. You can imagine as a web service in each of this application, right? The backend application could be an ERP, HR or finance system which offers various services. And this services within the systems like ERP and HR is the actual implementation of the logic. So understanding the positioning of PO in the overall system architecture is very important when you're trying to build an interface and when you're trying to define the even the architecture of the interfaces, you know, where we should put what. Now don't be confused with the presentation layer integration layer and the backend layer. So PO is the integration layer, right? I hope this will give you a solid understanding of where and how the PO is being laid out in the entire system. Architecture. Well, that's the end of this topic. If you have any questions regarding the topic I've discussed or any clarification on this topic, please feel free to join the discussion in the forum where I can spend time to answer your queries. You can always reach us at supported the podcast.com for any kind of questions without hesitation. With that I end this presentation and thanks for listening to this section of the course. Have a wonderful day. Bye.