sap process orchestration что это
SAP PI/PO Tutorial: What is Process Integration & Orchestration
Updated December 11, 2021
What is SAP PI?
SAP PI (Process Integration) is an enterprise integration platform that provides seamless integration between SAP and non-SAP applications within the organization A2A (Application to Application) or even outside the organization B2B (Business to Business). It allows organizations to exchange information between internal softwares within the company and external systems outside the company.
The SAP PI full form is Process Integration.
What is SAP PO?
SAP PO (Process Orchestration) is a tool for automation and optimization of business processes. It combines features of SAP Business Process Management (BPM), SAP Process Integration (PI), and SAP Business Rules Management (BRM). In other words, SAP Process Orchestration is a more advanced version of SAP PI and has all the tools required to integrate applications.
The SAP PO full form is Process Orchestration.
Understanding SAP PI/PO with an Example
But this was a technical aspect of SAP PI, but to understand this better we will see the example of implementation of SAP Process Integration.
Example:
To understand the concept of SAP PI more clearly, we take an example of a large-scale Dairy Industry, which is operating in a large portion of a state and dominating the region. But there is some small-scale dairy industries operating in the same region, parallel to the large-scale industry which is not making a profit due to their price variation compare to large-scale industry. So to avoid the pricing conflict and maintaining the same price all over the region, large scale and small scale industry decide to link together, with the help of SAP PI. They interconnect with each other with the help of SAP PI and started to work as a single unit. Now, through SAP PI they are able to exchange all the information pertaining to dairy industry, including pricing and share an equal amount of profit.
In this SAP PI/PO tutorial, we will learn
Why SAP PI/PO?
Prior to SAP PI, business would connect with each other through point-to-point communication. But this process is not used for multiple and complex processes. For smooth communication between multiple businesses, Mediated communication or Integration broker is used, and SAP PI adapts this system very well. It enables interconnection of a different process via a central location known as Integration Broker, unlike the point to point connection which is more like a spider web. The integration broker or server is an integral part of mediated communication consist of Java based Advanced Adapter Engine (AAE) and an integration engine for routing. Mediated communication is based on an integration broker which is executed by exchanging XML messages.
SAP PI PO Overview
Let see how SAP PI handles the XML messages by the help of Integration Broker. The exchange of data or message in SAP PI occurs in this four phases.
Next in this SAP PI tutorial, we will learn How SAP PI/PO works.
How SAP PI/PO works
SAP PI performs three basic functions
Next in this SAP PO tutorial, we will learn about SAP PI PO architecture.
SAP PI/PO Architecture
SAP PI/PO Architecture
SAP PI is not a single component responsible for the integration of SAP and Non- SAP application, but it is a cluster of components that together make SAP PI functional. This architecture of SAP PI or components is used during design time, configuration time and at run time. The various components of SAP PI include
System Landscape Directory:
It is a central information provider in a system landscape. SLD contains two types of information, “Component Information (Installable & Installed) and Landscape description.”
Integration Builder:
It is a tool-set which contains a set of tools for accessing and editing integration objects
Integration Repository:
To develop, design and maintain data types, message structures, mappings, interfaces, integration processes and integration scenarios independently of system landscape, integration repository is used.
Integration Server:
It is a central processing engine of the PI. All messages are processed using this server.
Central Monitoring:
With the help of this monitoring of PI domain is done, and “workbench” is the tool that is used for monitoring.
Adapter Engine:
It acts as a connector to connect the integration engine to SAP systems and other systems.
Message Processing Technique by PI:
To access data from SAP and Non-SAP application this technique is used. SAP PI uses an intermediate document like IDoc to Flat files to transfer their data.
Design:
Process Integration (PI) uses integration repository to design message structure
Configuration:
Integration Directory (ID) is used to configure technical parameters for objects created in IR ( Integration Repository)
Message Processing:
Once the IDOC is activated in SAP system, PI takes in charge and convert messages into XML format for its internal processing
Message Monitoring:
The messages can be monitored and traced using “Run Time Workbench”. This tool can be useful in monitoring sender and receiver adapters, Outgoing and Incoming messages, End to End monitoring of complete scenario and error traces.
Connectivity: Proxy Framework & Adapter Framework
Adapter Framework:
SAP PI connects with any external systems (SAP or Non-SAP) using the Adapter Framework. The adapter framework is based on the AS Java runtime environment and the connector architecture (JCA) version. The adapter framework consists of two default module chains if message processing is to be executed entirely within the adapter, default module chain for the adapter can be used.
There are four types of Adapters used in SAP PI
Other interfaces supported by adapter framework are
How adaptor framework works?
SAP PI/PO Security
For messages, SAP PI provides the message level security for XI message protocol, for the SOAP adapter, for the RosettaNet protocol, for mail adapter, for the CIDX protocol and for connectivity with WSRM (Web Service Reliable Messaging) enabled systems. In SAP PI message level security enabled through the use of encryption, digital signature, SAML Assertion, Username token, Certificate token, etc. Authentication methods supported by WS infrastructure for transport level includes basic authentication (Password and Username), SAP assertion ticket, and HTTP over SSL.
Connecting Integration Server with WSRM (Web Service Reliable Messaging) Enabled System
To connect with WSRM enabled system you use a communication channel of adapter type WS.
Benefits of Security in SAP PI/PO
New Features in SAP PI/PO
The new features in SAP PI include
Русские Блоги
Начало работы с SAP PI
Начало работы с SAP PI
содержание
текст
Что такое SAP ERP
Прежде чем мы войдем в тему, мы должны признать следующие моменты:
Устаревшая система
При внедрении SAP в крупной организации не все компоненты можно разместить в SAP ERP. Многие из этих бизнес-компонентов имеют собственные проприетарные инструменты, которые могут быть чрезвычайно сложными и не подлежат замене. Они работают параллельно с системой SAP. Их называют «устаревшими системами». Необходимо интегрировать эти уже существующие системы, не относящиеся к SAP, с SAP, и именно здесь появляется SAP PI.
Зачем нам нужен SAP PI
В крупных организациях, помимо устаревших систем, SAP ERP не состоит из одной системы, а объединяет несколько систем, таких как CRM, SRM и FICO. Чтобы справиться с этой сложностью, SAP представила PI: платформу, которая может предоставить единую точку интеграции для всех систем. Нет необходимости касаться сложной сети существующих устаревших систем. Это мощное промежуточное программное обеспечение, которое может обеспечить плавную сквозную интеграцию между SAP и другими приложениями, внутренними и внутренними или между внутренними и внешними. SAP PI поддерживает обмен B2B и A2A, поддерживает синхронный и асинхронный обмен сообщениями и включает встроенный механизм для проектирования и выполнения PI.
Архитектура SAP PI
Мы можем разделить PI на несколько областей:
Сервер интеграции является центральным механизмом обработки SAP PI. Здесь все сообщения обрабатываются единообразно. Он содержит три независимых движка:
Что касается механизма бизнес-обработки, эта статья объяснит позже.
В конфигурации и мониторинге вы можете отслеживать сообщения и адаптеры.
Один стек и двойной стек
Когда PI был впервые выпущен, не все компоненты были построены на одной платформе. Механизм интеграции и механизм бизнес-обработки создаются ABAP, а механизм адаптера, построитель интеграции, SL, CM и среда выполнения сопоставления создаются Java. Следовательно, для работы PI требуется среда Java и ABAP, которая называется двойным стеком.
Но в более поздних версиях все компоненты построены на Java. Некоторые компоненты с двойным стеком были упразднены или запускались в стеке Java после модификации. Следовательно, для работы PI требуется только среда Java. Это единый стек.
(Одиночные и двойные стеки имеют свои преимущества и недостатки, но эта статья не будет включать связанный контент)
Механизм интеграции
Механизм интеграции отвечает за службы центрального сервера интеграции, такие как этапы конвейера: маршрутизация и сопоставление. Если структура исходного сообщения и структура целевого сообщения различаются, механизм интеграции вызывает Mapping Runtime, и исходная структура будет преобразована в целевую структуру. Mapping Runtime основан на стеке Java. Механизм интеграции также можно преобразовать с помощью программы ABAP, которая основана на стеке ABAP.
Сообщения могут быть двух типов:
В PI сообщения представлены интерфейсами.
Интерфейс: Структура сообщения и описание в формате XML.
Исходя из вышеуказанных ограничений, существует три типа интерфейсов:
При настройке логики (сценария) интеграции для каждого бизнес-требования в PI механизм интеграции выполнит настройку пошагово. Термин «конвейер» относится ко всем этапам, выполняемым при обработке сообщения XML. Этапы конвейера включают:
Адаптер двигателя
Вы, должно быть, обнаружили, что механизм интеграции использует только протокол XML-SOAP для обработки сообщений. Но если у нас есть пара отправляющих и принимающих систем, их форматы данных разные? В настоящее время мы используем различные адаптеры в ядре адаптера для преобразования сообщений на основе XML и HTTP в указанные протоколы и форматы, необходимые для этих систем, или наоборот.
RFC adapter, SAP Business Connector adapter, file/FTP adapter, JDBC adapter, JMS adapter, SOAP adapter, Marketplace Adapter, Mail adapter, RNIF adapter, CIDX adapter
IDOC adapter and HTTP adapter
Когда SAP PI перешел с двойного стека на одинарный, эти два адаптера стали частью стека Java. Модифицированный механизм адаптера становится усовершенствованным механизмом адаптера, и два адаптера называются IDOC_AAE и HTTP_AAE.
Двигатель обработки бизнеса
Механизм бизнес-процессов (Business Process Engine) отвечает за выполнение и сохранение процесса интеграции.
BPM означает межкомпонентное управление бизнес-процессами (Business Process Management) или ccBPM, также называемое интегрированным процессом. Процесс интеграции относится к выполнимой межсистемной обработке сообщений. В процессе интеграции вы можете определить все этапы обработки и соответствующие параметры управления процессом, которые необходимо запустить. Управление бизнес-процессами обеспечивает SAP Exchange Infrastructure, включая следующие функции:
Во время работы BPE выполняет процесс интеграции. Процесс интеграции может отправлять и получать сообщения только через абстрактный интерфейс.
Создайте сценарий в SAP PI
Если вам нужно создать сценарий в PI, начните с домашней страницы.
Интерфейс домашней страницы выглядит следующим образом:
На домашней странице есть гиперссылки на следующие четыре рабочие области:
Корпоративная сервисная библиотека
Используйте библиотеку корпоративных сервисов для проектирования и создания объектов для создания сцен. Поток данных в PI выглядит так:
Найдите следующие варианты дизайна:
PI использует интегрированную библиотеку для разработки структур сообщений для отправителей и получателей и разрабатывает интерфейсные сообщения через соответствующие структуры сообщений.Интерфейсные сообщения являются точкой взаимодействия с внешним миром. Типы данных и типы сообщений могут использоваться для упрощения и модульного построения сложных интерфейсов.
Оперативное сопоставление позволяет преобразовывать исходную структуру в целевую. Но если исходная структура и целевая структура совпадают, процесс может быть освобожден от выполнения. Подобно интерфейсу службы, отображение сообщений используется для упрощения и блокировки отображения сложных операций. Отображение сообщений может быть выполнено четырьмя способами:
(Есть и другие аспекты, которые не рассматриваются в этой статье)
Интегрированный каталог
Здесь мы используем настроенный ранее объект ESR для выполнения шагов конвейера. Эти шаги выполняются механизмом интеграции во время выполнения.
Прежде чем мы начнем настройку, нам нужно создать / импортировать следующие объекты в DIR:
Сервисы позволяют обрабатывать отправителя или получателя сообщения. В зависимости от цели использования этих услуг вы можете выбрать следующие виды услуг:
Канал связи определяет внутреннюю и внешнюю обработку сообщений. Сообщение будет преобразовано из собственного формата в формат сообщения, указанный в soap-xml через адаптер, или наоборот. Обычно в сцене есть два канала связи:
Канал должен быть выделен для службы. В зависимости от того, считается ли служба отправителем или получателем сообщения, канал также будет иметь роль отправителя / получателя, и они должны совпадать. Невозможно назначить каналы интегрированным технологическим службам.
Шаг конвейера DIR настраивается с помощью следующих четырех шагов:
Протокол отправителя определяет, как сообщение отправителя преобразуется, чтобы оно могло быть обработано интегрированной системой. Это содержит:
Протокол отправителя аналогичен первичному ключу в таблице. В одном плане не может быть двух одинаковых соглашений об отправителях.
Протокол получателя определяет, как сообщение преобразуется в форму, которую получатель может обработать. Это содержит:
Используйте суждения получателя, чтобы указать, кому отправлено сообщение. Вы можете пересылать сообщения, определяя условия, которые включают:
Системное планирование
SAP System Landscape Directory (SLD) является поставщиком основной информации для системного планирования. На веб-странице вы можете найти следующие ссылки:
Интерфейс SLD показан на рисунке ниже:
И продукты, и компоненты можно назвать информацией о компонентах.
И техническая система, и бизнес-система называются описанием ландшафта.
Бизнес-систему можно настроить как интегрированный сервер или систему приложений.
Только один клиент в системе SAP может быть настроен как интегрированный сервер.
Следующая информация извлекается из SLD в ESR и DIR:
Бизнес-система, используемая в каталоге для определения отправителей и получателей сообщений.
Конфигурация и мониторинг
Интерфейс настройки и мониторинга выглядит следующим образом:
Конфигурация и мониторинг поддерживают следующие функции мониторинга:
Синхронный против асинхронного
Обработку можно определить как синхронную или асинхронную.
Таким образом, обмен сообщениями можно разделить на три категории:
В PI мы определяем их как: синхронный-BE (Best Effort), асинхронный и неупорядоченный-EO (Exactly Once), асинхронный и упорядоченный (Exactly Once in Order).
подтверждать
Для синхронной связи, когда система A вызывает систему B, если B не может отправить ответ, обработка завершится ошибкой. Но при асинхронной связи система A вызывает систему I, а система I вызывает систему B. Итак, предположим, что связь между A и I успешна, но связь между I и B не работает. Как A узнает, что процесс, отправленный B, потерпел неудачу? Это реализуется посредством подтверждения, которое отправляется к A в обратном направлении через тот же метод маршрутизации сообщения от A к B. Если подтверждение от B к A не доходит до A, то A сочтет обработку неудачной и отправит сообщение снова.
Когда мы говорим об асинхронности в PI, мы будем использовать термин «ровно один раз» для обозначения EO и EOIO. Именно Onc означает, что однажды отправленное сообщение не может быть отправлено повторно. Для достижения этой функции каждое сообщение, отправленное от A к B, будет иметь подтверждение. Терминалом связи является адаптер, поэтому адаптер должен поддерживать подтверждение.
Все адаптеры обеспечивают подтверждение системы, например подтверждение отправки. Адаптер, поддерживающий синхронную связь, поддерживает подтверждение приложений в дополнение к подтверждению системы.
Итак, в PI есть следующие типы подтверждений:
Remote Function Call
При выполнении работы PI вы столкнетесь с существительным-RFC. что это? Чтобы установить соединение между двумя системами SAP, такими как R / 3 и PI, мы создали цель RFC. Цель RFC должна настроить следующее:
Тип соединения описывает тип системного соединения, например R / 3, TCP / IP, внутреннее соединение и т. Д.
Созданные цели RFC можно классифицировать по типу связи. По асинхронному или синхронному общению его можно разделить на:
(Примечание переводчика: в дополнение к bgRFC)
What is the Difference Between SAP PI and PO?
Do you feel like there is a complete overhaul of the SAP middleware every 3 days? Ever wondered what are the differences between XI, PI and PO? Well, you are not alone! There have been major changes to SAP middleware XI/PI/PO in its lifetime. From first introduction of SAP XI in 2002, SAP has completely changed the architecture with their major version upgrades.
As an integration consultant you have to not just keep up with the new PI/PO technology and architecture changes, but be ready to deal with hundred new abbreviations that come with it. IE, IS, IR, ESR, AE, AAE, AEX, ccBPM, NWBPM?! Do not worry, I am not trying to confuse you more with these abbreviations. Not only will we compare the differences between SAP eXchange Infrastructure (XI), Process Integration (PI) and Process Orchestration (PO), but also look at different components that belong to each version. Also, we will compare new components available in SAP PO and what components have become obsolete in PI/XI versions due to the introduction of java only PO architecture.
For us to understand the differences between XI, PI and PO, first, we need to look at main functionaries of middleware,
What is Middleware:
Connectivity: Which protocol to use – SOAP, FTP?
Routing: Who are the receivers of the message – Multiple receivers? Condition based routing?
Transformation: What kind of conversion or mapping required? XML to text?
Runtime: messages monitoring and security
Workflow (BPM): How to execute a series of steps? Integration scenario with a Purchase Order approval process?
SAP has been able to cover all these areas successfully with SAP PI/PO middleware solution.
Overview of SAP Middleware Versions:
First SAP eXchange Infrastructure (XI) was introduced in 2002 with version XI 2.0. This was a dual stack option with ABAP and Java stacks. After a few versions of XI, SAP introduced SAP Process Integration (PI) 7.0. PI single stack only installation option was introduced with PI 7.3 in 2010. Finally, in 2011 SAP introduced PO (Process Orchestration) with version 7.31.
Evolution and history of SAP XI, PI and PO and their versions
To understand the differences between these versions, let’s look at the major architecture changes of each.
SAP eXchange Infrastructure (XI) Architecture Overview:
SAP eXchange Infrastructure (XI) contains Adapter Engine (AE), Integration Engine (IE), and Business Process Engine (BPE). It was installed on a dual stack Netweaver installation with ABAP and Java stacks.
AE – Adapter Engine
As the name suggests, the main purpose of this component was to provide connectivity functionality. Adapter engine provided capabilities of talking to different communication protocols using different adapters.
IE – Integration Engine
SAP XI component which was responsible for transformation and routing of the messages. Integration Engine also provided a runtime to the message communication. In XI heavy message processing was done through IE as each message was routed, transformed and executed by this component.
BPE – Business Process Engine
Engine which executed ccBPM (Cross Component Business Process Management) workflows. ccBPM is based on Business Process Execution Language (BPEL) and required a dual stack installation as its runtime enviornment was on Web AS ABAP.
Drawbacks and Challenges with eXchange Infrastructure (XI):
One major drawback of XI inefficient performance due to back and forth communication between components. Also due to the dual stack arcitecture and multipole components, message persistence impacted the performance.
SAP Process Integration (PI) Architecture Overview:
With SAP introducing Advanced Adapter Engine (AAE), PI was able to process messages end to end without Integration Engine (IE) runtime. This reduced the cross communication between components and improved performance massively.
AAE – Advanced Adapter Engine
AAE has capabilities to handle routing, transformation and connectivity which were segregated to different components in SAP XI. Integration Configuration Object (ICO) was introduced for design time instead of traditional XI objects such as sender agreement, receiver determination and receiver agreement. ICO made it possible to connect, transform and route message in AAE without Integration Engine (IE) runtime. Also, dual stack message persistence was eliminated since ICO scenarios were executed independently by AS Java.
Drawbacks and Challenges of PI with AAE
Although PI installation with AAE enhanced performance in comparison with XI, still improvements were needed to extend connectivity and performance. AAE could only handle limited set of connections and still required IE runtime for development and administrative purposes. Plus, RNIF adapter and the CIDX was not available in AAE. Also, earlier versions of AAE did not include iDoc and http adapters since they belonged to ABAP stack. Moreover, BPE still required ABAP stack for runtime as it was ccBPM. As you notice, although performance was improved compared to XI, SAP couldn’t completely decouple the need of Integration Engine (IE).
B2B Add-on
B2B add-on was also introduced to PI with versions PI 7.1. B2B comes with a set of B2B protocol adapters, converter modules and B2B infrastructure services for serving the EDI integration needs of most industries.
Finally, with SAP PI 7.30 version SAP eliminated the need of Integration Engine (IE) and introduced the Advanced Adapter Extended (AEX). AEX is a single engine which includes Enterprise Service Bus (ESB), Integration Directory (ID) and AAE capabilities. With AEX, PI became a Java AS only installation and SAP completely decoupled ABAP stack. Also with PI 7.3 SAP introduced iDoc_AAE adapter and http_AAE which run on Java. The complete removal of ABAP stack is a major change in the SAP PI architecture.
Drawbacks and Challenges of PI with AEX
Although PI with AEX improved performances by completely decoupling ABAP stack and the need of Integration Engine (IE), it did not include Business Process Management (BPM) capabilities.
SAP Process Orchestration (PO) Architecture Overview:
To overcome all these challenges with PI, SAP released Process Orchestration which was a Java only installation. Yes! No ABAP stack installation was availabe from PO 7.31. Plus, with new PO version SAP has added fully functional Netweaver Business Process Management (NW BPM) and Business Rule Management (BRM) which were fully executable on Java. Therefore, Process Orchestration (PO) is a combination of Process Integration (PI) with AEX, Business Process Management (BPM) and Business Rule Management (BRM) which only runs on Java.
NW BPM – Netweaver Business Process Management
Unlike ccPBM, NW BPM runs on Java-based environment called CE (Composite Environment). Also, NW BPM uses Business Process Model Notation (BPMN) language while ccBPM uses Business Process Execution Language (BPEL). Although ccBPM design time was on ABAP stack, you require Eclipse based tool NWDS (Netweawer Development Studio) for NW BPM. Even if you have extensive experience in ccBPM, you need to start learning NW BPM from scratch.
BRM – Business Rule Management
Business Rule Management (BRM) contains modeling capabilities targeting business analysts. Rules are owned by LoB not by IT.
Summary:
To conclude, SAP PO contains all the functionalities of PI, plus BPM and BRM in a single Java stack. I hope you were able to visualize the evolution of SAP middleware. By looking at the history of changes to SAP middleware architecture from XI to PI to PO, you can see the reasoning behind these changes. If you have any more questions comment below!