
After my last post, Tim S.e-mailed a question that’s very relevant to our discussion of middleware solutions. He wanted to know, “Just what is Process Orchestration and how is it different from Process Integration, or an AEX?” Obviously, there are some excellent courses on this topic, including SAP NetWeaver Process Integration (BIT400) and Process Orchestration Overview (BIT800). But before you dive into training, I’d like to use this week’s blog to explain the concept of process orchestration, and offer a brief (but necessary) history lesson.
From a generic perspective, process orchestration is the idea that you can take business processes that are inefficient and time consuming, and use middleware tools to convert them to run more effectively across your business.
SAP offers an on-premise middleware solution called SAP Process Orchestration that helps automate and optimize business processes, and transform them from simple workflows to integrated processes that work across multiple applications and organizational boundaries. At a high level, this technology makes it possible to:
Of course I haven’t answered the second part of Tim’s question. That is, how is process orchestration different from Process Integration, or an AEX? I know we technology geeks don’t spend a lot of time studying history. But to answer this, I think we should take a trip back in time and see the progression of process orchestration middleware.
Process orchestration: A history lesson
In the beginning there was Exchange Infrastructure (XI). XI was a dual stack application. The adapter engine, Integration Repository, and Integration Directory were on the JAVA stack. The Central Integration Engine and the Business Process Engine (BPE) were on the ABAP stack.
Adapter Engine was responsible for two actions: Connecting to and from XI, and converting a message format to a usable SAP XML formatted message. Central Integration Engine was responsible for routing and transferring a message. Business Process Engine was based on a SAP Workflow Engine. The BPE was a very system centric BPM tool based on BPEL4WS.[MC1]
The components of Exchange Infrastructure included:
XI 3.0 grew into Process Integration (PI) 7.0. For developers, Basis, and architects, not much changed other than the name.
There were big changes in 2007. For Basis, the changes where not very big but for the developers and architects the changes were worth taking a look at. The Integration Repository grew and become the Enterprise Service Repository and the Service Registry was added to design time.
Components of Process Integration (PI) included:
In 2010 things got interesting for Basis and architects. SAP introduced the Advanced Adapter Engine Extended. You had a choice to run your middleware either in a traditional ABAP/JAVA stack, or in a JAVA stack only. One concern was that you’d lose the ccBPM capability. But you had a lower cost of ownership. But this was an option if you just needed a robust enterprise service bus to transform messages to and from your SAP environment.
Components of the Advanced Adapter Engine Extended included:
Wow, in 2011 things got fun for everyone. We now had PI 7.31, PI AEX 7.31 and the new kid on the block, Process Orchestration! Now it’s easy to see this as the next version of PI, because it does message transformation, but it also does much more.
Components of Process Orchestration include three existing SAP programs:
Understanding what the components of SAP Process Orchestration can do
With that background, here’s more detail on what the components of this middleware solution can help you accomplish:
Support process improvement projects by making it easier for business and IT teams to jointly compose executable processes using standardized notation.
Connect heterogeneous systems and achieve application-to-application (A2A) and business-to-business (B2B) integration.
Compose, execute, and maintain business rules across your enterprise – so you can improve agility and decision making.
More than routing and transforming messages
Here’s my take: Process orchestration (PO) is more than just routing and transforming messages. If that is all I want to do then I would look at a PI configuration. But let’s face it, the days of simply taking a message and routing it to another system are few and far between. With the speed of today’s business environment coupled with new technologies, a company needs to be able to make changes and know the impact of those changes – quickly!
Ask yourself these two questions: First, on the last interface you created or changed, if you had to changed it tomorrow would you know what the impact would be to the business process? And second, the big one...did you document it? Be truthful!
When I want to take messages, make them a part of a business process that may involve system and human-centric tasks that cross multiple systems both SAP and Non SAP. Oh, and I want to keep the control on premise. SAP Process Orchestration is your tool.
“But,” you may ask, “what if I want to do cloud integration?” That’s easy. Check out my next blog to learn about SAP HANA Cloud Integration.
I hope you’ve been rebooted, with a better understanding of where SAP Process Orchestration fits. If you have questions, please feel free to ask them below as a reply to this blog![MC3]
Any questions drop me line j.valladares@sap.com
Resources to help you
Get “how to” training:
Check out these reference sites on the SAP Community Network:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
16 | |
14 | |
13 | |
11 | |
11 | |
11 | |
10 | |
8 | |
7 | |
6 |