VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Počítačové systémy

Transcription

1 VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor Počítačové systémy Implementation of SAP PI system as the central point for data exchange in heterogeneous IT environment of RIETER Company bachelor thesis bakalářská práce Autor: Michal Kratochvíla Vedoucí práce: MSc ETH EEIT, MAS ETH MTEC David H. Gehring Jihlava 2015

2

3 Abstract The aim of this project is to define and implement a suitable solution for the complex data exchange in the IT environment of the RIETER Company worldwide. After the comparison of the Peer-to-Peer and the Mediated communication concept the Mediated communication was chosen. Evaluation of the particular solution based on SAP technologies proved SAP Process Integration as the right choice for the implementation. The design and configuration components of a general data exchange (integration) scenario as well as an example of the real scenario are described within this study. Key words Data exchange, SAP NetWeaver, SAP PI, Peer-to-peer, Message broker, Mediated communication, SOAP, RFC, XML, ABAP, Java, Enterprise Service Repository, Integration Directory Anotace Účelem tohoto projektu je nalézt a nasadit vhodné řešení pro komplexní výměnu dat v globálním IT prostředí koncernu RIETER. Po porovnání metod Peer-to-Peer a zprostředkované komunikace byla vybrána metoda zprostředkované komunikace. Vyhodnocení vlastností konkrétního řešení založeného na technologiích SAP prokázalo použití systému SAP Process Integration jako vhodnou variantu pro implementaci. Součástí této práce je i návrh a konfigurace komponent obecného i konkrétního scénáře pro výměnu dat v prostředí SAP PI. Klíčová slova Data exchange, SAP NetWeaver, SAP PI, Peer-to-peer, Message broker, Mediated communication, SOAP, RFC, XML, ABAP, Java, Enterprise Service Repository, Integration Directory

4 Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též AZ ). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ. Byl/a jsem seznámen s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutí licence. Ve Velké Bíteši dne Podpis

5 Poděkování Tato práce by nikdy nevznikla bez podpory několika lidí, kterým bych na tomto místě rád upřímně poděkoval. Především mým rodičům náleží můj hluboký vděk za neustálou podporu během mých studií. Pan David Gehring si zaslouží velké poděkování za starostlivé vedení mé bakalářské práce a za mnoho cenných rad a připomínek. Pan Daniel Bussinger si zaslouží zvláštní zmínku a poděkování za jeho cenné rady, podporu a pomoc s jazykovou korekturou. Acknowledgements This thesis would have never existed without support of several people, whom I would sincerely like to thank here. First of all, my parents are due my deep gratitude for their continued support throughout my studies. Mr. David Gehring deserves big thank for his careful supervision of the project and for many valuable advices and remarks. Mr. Daniel Bussinger deserves special recognition and thanks for his valuable advices, support and help with language corrections.

6 Table of Contents 1 Preface Introduction of RIETER IT environment of RIETER Introduction to data exchange techniques Mediated communication and its technologies SAP PI general overview Data formats, protocols, adapters Implementation of mediated communication Position of SAP PI in the RIETER IT environment System architecture Integration engine Adapter engine Design and configuration tools Enterprise Service Repository Integration directory Management and monitoring Data exchange process design and configuration Design objects Configuration objects Summary of the typical components of an integration scenario HR Data distribution Involved systems Process components Integration scenarios design and configuration Conclusion and Outlook Resources and references List of pictures List of tables Abbreviations and explanatory notes Appendices... 52

7 1 Preface Data exchange between all the IT systems used either internally in the company or externally by 3 rd party partners is crucial for proper implementation of business processes. Correct, reliable and on-time support of all critical business processes requires a stable and efficient infrastructure for the exchange of structured data in defined formats. Such an infrastructure must support wide variety of data exchange technologies as different IT systems involved in the data exchange only have limited possibilities of data import/export. One of the major advantages of well-designed data exchange infrastructure is the single point of data maintenance the data is created, updated or deleted exclusively in the source system and then synchronized through the data exchange infrastructure with other systems, which use the data for their operations. The aim of this study is define the proper platform for the data exchange infrastructure within the IT environment of RIETER Machine Works Ltd. (referred to as RIETER further in this work) and to provide an overview of the available application integration techniques and standards and their implementation. 1.1 Introduction of RIETER RIETER [1] is the leading supplier on the world market for textile machinery, components and Aftersales services for short staple fiber spinning. Based in Winterthur (Switzerland), the company develops and manufactures machinery, systems and components used to convert natural and manmade fibers and their blends into yarns. RIETER is the only supplier worldwide to cover spinning preparation processes as well as all four final spinning processes currently established on the market. With 18 manufacturing locations in ten countries, the company employs a global workforce of some 5 000, about 24 % of whom are based in Switzerland. RIETER is listed on the SIX Swiss Exchange. The company comprises of three Business Groups: Machines&Systems develops and manufactures machinery and systems. After sales serves the clients over the whole product lifecycle with spare parts and value adding services. Components supplies 1

8 technology components and service offerings to spinning mills and also to machinery manufacturers. RIETER is a strong brand with a long tradition. Since the company was established, RIETER s innovative momentum has been a powerful driving force for industrial progress. Products and solutions are ideally tailored to its customers needs and are increasingly also produced in customers markets. 1.2 IT environment of RIETER RIETER relies on several core IT systems supporting all business processes including sales, marketing, products development, after sales support and many others. Apart from the systems used internally in the company it is also a need to exchange data with external partners (customs declarations, supply chain management etc.). Central point of the IT infrastructure within RIETER is a SAP NetWeaver system (SAP NW), particularly its implementation called 'ECC' (Enterprise/ERP central component). SAP ECC is not an isolated system and it needs to communicate with other systems used for various purposes (CRM, HCM, Microsoft Active Directory, access management system, production management system and many others). Those systems can either be a SAP based systems (HCM, Central User Administration) or generally any systems based on proprietary technology (communication and collaboration, production management system, database systems etc.). Both servers and clients generally run on Microsoft Windows technology taking advantages from the whole portfolio of Microsoft s standardized software solutions (Microsoft SQL Server, Microsoft Office, Microsoft Visual Studio and others). One important exception is the system used for communication and collaboration (mail system, documents sharing, groupware, workflows, etc.) this task is ensured by IBM Notes/Domino system, but still running on Microsoft Windows Server. As global company, RIETER needs to have reliable, secure and fast enough WAN connection between the headquarters and the subsidiaries. Such a connection is realized on leased lines with the support of standardized firewall, WAN optimization and LAN hardware. LAN connections are generally built on 1Gb technology with the backbone connections running on 10Gb copper and optical fibres technology. 2

9 2 Introduction to data exchange techniques This chapter describes the available methods of exchanging data between applications and/or systems within an organization. Data exchange usually is an issue involving two independent systems. In general it does not matter if the involved systems are SAP, IBM Domino, CRM system, payroll software or any other systems. In this particular study I assume the exchange of data between the SAP system (as the central point of the IT infrastructure) and other systems (both SAP and non-sap) within the system landscape. The systems used in large organizations, are not simple and single-purpose usually. Systems like SAP or IBM Domino are very complex and highly structured systems, offering a large variety of capabilities available for the customers of the IT department of a company the business users. Complex tasks solved by IT systems are divided into smaller and simpler particular tasks, which process their pieces of data in a defined way and then bring their result either into another particular task or into the common complex mosaic of the final result. These particular tasks will be called process components further in this work. Even if the systems, like IBM Domino, can work and serve their services more or less independently, their real strength and major benefit lies in the possibility of interoperability with other systems. Sales representatives can collect contact information about prospective customers during their business trips or trade fairs, store them into a Domino database and once they connect to the network they can update the master database of contact information in SAP with the newly acquired contacts. Servicemen can have full catalogues of products, parts and materials accessible wherever they are in their local replicas of Domino databases, which import products, parts and material data from the SAP Master databases. When talking about data exchange between two independent systems, then it actually means data exchange between two process components, one inside of each complex system. The ABAP routine, which exports material data from SAP (process component on SAP side) and the LotusScript agent, which reads the exported data from a text file and creates or updates corresponding documents in a Domino database (process component on Domino side) could be two examples of such process components. 3

10 As this way of data exchange is not organized in any standardized way, each pair of process components can use its own data format (e.g. text files, CSV files, XML files etc.). In case of more participating components the communication between them can look like spaghetti. This way of communication between systems is called Peer-to- Peer communication. See picture 1. It is worth to be mentioned that the format of the data exported from the sender component must perfectly fit the expected data format of the receiver component. There could be a problem to find one common communication technique in some cases, for example one system supports only JDBC database access, while the other system is only capable to receive data in the flat file format. SAP System landscape Foreign system Process Component 1S Process Component 1F Process Component 2S Process Component 2F Process Component 3S Process Component 3F Process Component 4S Process Component 4F Picture 1: Peer-to-Peer communication If, for example, the process component 1S on picture 1 is updated, then most probably both connections to the process components 1F and 4F also must be updated (whatever the update means different format of exported data, new authentication method, etc.). This approach could easily get out of control since the number of connections rapidly grows with the number of process components. 4

11 As the goal of the implementation of the data exchange infrastructure is to efficiently manage, monitor and operate the data exchange, it is necessary to think about any other approach to the process. A central instance, which interconnects all involved systems (process components), could bring a lot of benefits and it could be the right solution for data exchange in a complex IT environment of big companies as shown in picture 2. SAP System landscape Foreign system Process Component 1S Process Component 1F Process Component 2S Process Component 2F Integration Broker (mediator) Process Component 3S Process Component 3F Process Component 4S Process Component 4F Picture 2: Mediated communication This scenario offers the option to have all data exchange-relevant information and processes integrated into one central point. Also the number of the connections is significantly lower than in case of Peer-to-Peer communication (the number of connections is equal to the number of process component) and the management of the connections is easier. The central element in the picture 2 is called integration broker or mediator. The way of such an interconnection is then called mediated connection or mediated communication. 5

12 The mediated communication between two process components is executed by exchanging structured messages. XML format proved its ability to become a standard in this area. This type of communication is accordingly called message-based integration. The role of the mediator basically is to manage the connections to all involved process components and to receive their messages, transform them to the proper format and then to send them to the other process component. Picture 3 displays an example of communication between two process components. In this particular example, the ABAP routine, generating a list of materials on SAP side, is process component 1. The LotusScript agent on Domino side, importing the data to the Material database, is process component 2. Message 1 Integration Message 2 Process Component 1 (e.g. Idoc) broker (e.g. SOAP) Process Component 2 (mediator) Picture 3: Details of mediated communication between two process components The mediator in this case transforms the incoming message to the outgoing message and performs data mapping. Mapping means, that the mediator assigns fields of the incoming structure to specific fields of the outgoing structure and/or transforms business data in the payload of the message (e.g. changes the format of date from YYYYMMDD to DDMMYYYY). The structure of the incoming and outgoing messages can be completely different, the mapping process ensures proper restructuring of the target message. The examples presented within this chapter and even in the rest of this study are related to the existing processes and systems within the IT infrastructure of RIETER. 6

13 3 Mediated communication and its technologies Mediated communication described in the previous chapter is the method, which is recommended by SAP as the pro-forma standard for the communication between the SAP system landscape and 3 rd party systems in the heterogeneous IT environment of larger enterprises. Within this chapter I will describe details of mediated communication with respect to the systems and technologies used in the IT environment of RIETER. As the core systems supporting the RIETER business processes are based on SAP NetWeaver platform, I will focus on proprietary SAP technologies supplemented by the generic industrial standards. Mediated communication is named by the mediator, which is the main component of the whole communication and data exchange infrastructure. SAP NetWeaver Process Integration (SAP PI) represents the role of the mediator in the system landscapes based on SAP technologies. SAP PI is not the one and only possible solution for mediated communication and generally for Application integration. Competitors like IBM WebSphere, MS BizTalk and others can offer basically the same or similar core functionality. System landscapes based on SAP technologies can however use the advantages of the tight coupling of SAP PI system with other SAP components in regard of security, data formats, communication technologies, system management and monitoring. SAP PI also supports all important industrial standards used in the area of the systems interoperability and data exchange. 3.1 SAP PI general overview From the SAP ECC point of view, the SAP PI stands between the world outside and the SAP ECC (SAP ERP Central Component). The SAP PI handles requests coming from the outside, transforms the messages and passes them to the proper process component in the SAP system landscape and vice versa. The connection to all involved systems (i.e. process components) is maintained by so called adapters contained in SAP PI. There is a variety of adapters available to connect to sender or receiver applications/systems which can be based on completely different application specific or technical protocols. Within this study I will mainly focus on 3 of 7

14 them only IDoc, SOAP and RFC adapters. All of them are standard part of SAP PI, so no 3rd party solution is needed. See picture 4 for a schematic description of the role of SAP PI. SAP NetWeaver System Landscape SAP ECC SAP NetWeaver Process Integration Idoc adapter Other adapters. RFC Adapter SOAP Adapter SOAP Message IDoc HTTP request Lotus Domino system Another SAP system (i.e. B2B) 3rd party system Picture 4: SAP PI role in the SAP system landscape 3.2 Data formats, protocols, adapters All data exchange is processed via standardized protocols, in defined data formats and using the proper adapters. Herein I will focus on basic data formats and technologies, which seem to be most efficient for the intended purposes (i.e. data exchange between SAP and 3 rd party systems in a secure, fast, well manageable and reliable way) IDoc message format Most of the data exchange inside the SAP system landscape (including SAP PI), is considered to run using the IDocs message format. IDoc stands for Intermediate document and represents the SAP document format for transferring data within a business transaction. IDoc is a structured data format similar to XML in its purpose, but different in the syntax. Each IDoc is obliged to have header information like e.g. its creator, creation time etc. 8

15 While XML has a tag-like tree structure containing data and meta-data, IDocs use structure which rather suggests a table with the data and meta-data [7]. Basic structure of an IDoc is as follows: Control record (contains the type of the IDoc and other header information) Data records (the structure is based on the IDoc type, in most cases it is fixed, but there is some flexibility) Status records 3 rd party systems, unlike SAP systems, usually do not have any proprietary mechanism to process an IDoc. That s why the IDoc adapter of SAP PI is not the right option for a data delivery to non-sap systems as IBM Domino for example, although the IDoc concept offers a wide variety of valuable secure, reliable and manageable methods for data exchange. However all the advantages offered by IDocs can be used while sending or receiving data to/from SAP systems. Here the advantage of the integration broker can be nicely seen communication between SAP PI and other SAP systems uses standardized communication technology (IDocs), while the communication between SAP PI and a 3 rd party system can use any other communication method that both parties do understand Web Services and SOAP protocol Many systems, including SAP PI or IBM Domino, offer the usage of so called Web Services as the technology for providing/consuming data to/from external systems. Web services are software components designed to support interoperable machine-tomachine interaction [2]. It means the Web services are not primarily dedicated to human usage. Each Web service has its interface described in standardized structured format called WSDL. The WSDL information contains the full description of methods offered by the Web service. Only the description of the Web service s interface is important and valuable for other systems, which will use (or consume) the methods offered by the Web service. The particular implementation of the Web service is not important and has no influence to the system which consumes the Web service. Neither matters if the software code of the Web service is written in Java, C++, LotusScript or any other programming language, nor it is important, if the Web service runs on an AS/400, Windows or UNIX server. 9

16 Other systems interact with the Web service via so called SOAP messages. SOAP stands for Simple Object Access Protocol and it is a protocol specification for exchanging structured information in the implementation of Web Services. SOAP messages rely on XML as the basis for their message format. The SOAP message transmission to/from the Web Service is usually ensured by another application layer protocol, mostly by HTTP or HTTPS [3]. As the Web service technology offers platform-independent data exchange in defined and structured format, it could be a good candidate to fulfil the expectations of the data exchange in many cases. Web services allow also authentication and authorization, so the requirement of security can be also observed RFC communication interface The standard RFC (Remote Function Call) is also available in the environment of the SAP system landscape. The RFC is a strong and valuable method of requesting/providing data which does not have a standardized IDoc message type assigned. For example, products data will definitely vary for a car producer and for a textile machine producer. That s why SAP does not offer any standardized IDoc message type for products data. Instead of using IDocs it is possible to use an ABAP function module in SAP ECC, providing all relevant product information. Such a function module can be then invoked remotely (e.g. from SAP PI) and it can provide relevant data for any 3rd party system. If a system needs to call functions on remote systems, then additional configuration in the sender (caller) system is necessary. Such a configuration is called RFC destination configuration and can be configured in the SAP transaction SM59. The RFC destination configuration contains the identification of the remote system, logon details, communication encoding and other connection parameters. I use the RFC connections from SAP PI for delivery of the data sent by non-sap system to our SAP systems as well as for retrieval of data during the message mapping (details will be explained in chapter 6). The following picture 5 shows an example of the RFC destination configuration. 10

17 Picture 5: RFC destination configuration 11

18 4 Implementation of mediated communication Following chapter contains the detailed overview of the implementation of the mediated communication in the particular software system (SAP PI) and its integration into the IT infrastructure of RIETER. SAP PI (in full name SAP NetWeaver Process Integration) is a software component of the NetWeaver product group. SAP PI can be classified as Enterprise Application Integration (EAI) software, which ensures interconnection of various systems and provides single point of integration for all systems without touching existing infrastructure of the systems within the company. RIETER has decided that SAP PI is the right choice for the application integration in the infrastructure of the RIETER IT systems. The decision was based on the thorough analysis of the business processes and the IT systems used inside RIETER as well as the analysis of the needs of the relevant IT systems of external business partners. The portfolio of the supported data formats and technologies makes SAP PI the ideal solution for the reliable and secure data exchange between all systems involved in the daily business of RIETER and its partners. I was involved in the analysis and decision phase and I got the opportunity to design, build and manage the whole data exchange infrastructure. The SAP PI system itself was installed by RIETER SAP Basis team early in I and an external consultant started with the system configuration and with the development of the first integration scenarios in May The successful go-live of the first particular integration scenario was on 1 st of July 2013 and since then many other scenarios were designed and configured. With the basic knowledge of the implementation of the same SAP PI system in two other companies (Noble Biocare Holding AG, Zürich and SBB AG, Bern) I can compare the various ways of the usage of the system. Each company has its own demands for the type of the data exchange and for the amount of the messages passing through the application integration platform. RIETER and SBB companies use SAP PI mainly for the internal or B2B data exchange, while Noble Biocare Company uses their SAP PI system mainly for handling of the customers orders (B2C). 12

19 4.1 Position of SAP PI in the RIETER IT environment The role of SAP PI as the central point for data exchange indicates its position in the IT environment of the company. SAP PI stands in the middle of all other IT systems which connect to the PI system via so called adapters (see chapter 3.1). Generally any data exchange should run via SAP PI so that the proper maintenance and the monitoring can be ensured. Nevertheless there are some exceptions. Picture 6 displays an overview of the position of the SAP PI system in the RIETER IT environment. SAP HCM Other SAP system(s) SAP ECC Lotus Domino server(s) Internet Firewall SAP PI Active Directory Workstations Other 3rd party systems Picture 6: Position of the SAP PI system in the RIETER IT environment The exchange of standardized data records between the particular process components which are integrated in SAP systems (e.g. SAP HCM and SAP ECC) runs directly between the involved systems using ALE technology. Such a data exchange is only possible for the data records which use the standard IDoc formats and do not require a message content manipulation. If at least one involved process component is designed to use a customized IDoc format (like for example any extension of the standard IDoc or newly designed IDoc structure), then such a data exchange must run via SAP PI system in order to guarantee correct delivery and acceptance in the receiving system. 13

20 Also non-sap systems do not necessarily need to exchange their data via SAP PI if the data is not sent to/from any SAP system (e.g. export of information from Lotus Domino database to MS Excel format). The option to use SAP PI is anyway available also for the communication between two non-sap system if reliability and monitoring of the communication is required. As the topic of this bachelor s thesis is the implementation of SAP PI system I will not take those exceptional data exchange techniques into consideration within this work. 4.2 System architecture The configuration of the SAP PI system used in RIETER is based on so called dual stack architecture. Dual stack means that the whole system is built on two technologies ABAP and Java. Integration engine, some monitoring features and some integration configurations are built in ABAP while Adapter engine, Integration Builder, Enterprise Service Repository, System Landscape Directory, Runtime Workbench and Mapping engine are built in Java [4] (the components will be closer described later in this document). The most up to date implementation of the SAP Application Integration system is based on single (Java) stack only and its name has changed from Process Integration (PI) to Process Orchestration (PO). As the Process Orchestration is not only newer version of SAP PI, but extends the capabilities of the Integration platform with process modelling, operation and monitoring of SAP NW BPM (Business Process Management) [5] and the implementation of such a system requires changes in the established business process, therefore RIETER does not plan to switch to the SAP PO single stack system at the moment. The architecture of the data exchange (or application integration in wider term) can be easily demonstrated on an example of a message processing. Picture 7 displays such a process. The example shows the role of two main components involved in the process of the data exchange Integration engine (which incorporates Mapping engine) and Adapter engine, which ensures translation of the process component's native protocol into the PI internal XML SOAP protocol. Additionally components for data exchange monitoring and system management and maintenance are displayed. 14

21 SAP NetWeaver Process Integration (SAP PI) Monitoring and configuration Mapping engine XML-SOAP Sending process component Native protocol Sender adapter XML-SOAP Integration server services XML-SOAP Receiver adapter Native protocol Receiving process component Outbound interface Inbound interface Integration Engine Adapter Engine Picture 7: Overview of SAP PI system architecture 4.3 Integration engine Integration engine is responsible for processing of the incoming data message and its routing to the proper interface. Integration engine understands XML-SOAP protocol only for both incoming and outgoing messages, so all operations which are performed inside the Integration engine are optimized for single protocol. Messages can be of two types: Synchronous Asynchronous Synchronous messages contain both request and response part. Their processing consists of 3 complex steps. Processing of the request message part Waiting for the response Processing of the response message part Generally request and response messages can have completely different structure and content. The big advantage of the synchronous messages is the possibility to ensure acknowledgement to the request message or to return information based on the request 15

22 (e.g. return list of customer s orders based on customer number provided in the request message). Asynchronous messages are easier for processing, they only contain data which should be processed and delivered to the target (receiving) system. No acknowledgement or response is expected for asynchronous messages. The message inside the Integration engine is represented by an interface. Interface = structure of the message in XML format + direction [4] There are two (in fact three, but for purpose of this thesis only two are relevant) types of the interfaces based on the direction of the communication: Outbound interface Inbound interface The naming of the interface types can be confusing outbound interface connects to the sender system and ensures receiving of the incoming message, while the inbound interface connects to the receiver system and ensures sending of the outgoing message. The naming is related to the sender and receiver systems and not to the Integration engine of the PI system. If the structure or the content of the source and target message differ, then the Integration engine calls Mapping engine (or Mapping runtime), which ensures translation of the structure and/or content. Mapping runtime is based on Java stack and has extensive possibilities of message structure and content conversion. Predefined functions or user defined Java programs or external ABAP programs and their combinations can be used for the structure and content translation. The configuration of complete data exchange logic (also called integration scenario) is executed by the Integration engine as can be seen in picture 7 and as described in this chapter. Generic integration steps performed by the Integration engine are: Source message acceptance Identification of the receiver Identification of the (receiver) interface Message split (if more than one receiver is identified) 16

23 Message mapping Message routing Adapter call The configuration and meaning of the particular steps will be described later in this document (see chapter 5). 4.4 Adapter engine As stated in the previous chapter the Integration engine can only process the messages in XML-SOAP format/protocol. But what if a sender or a receiver process component does not support XML-SOAP protocol or such a protocol is not effective to be used? Then the Adapter engine and its particular adapters play the important role. Adapters simply translate a process component's native protocol into XML-SOAP protocol and vice versa. Adapter engine ensures receiving of a message from a sender system (in the system's native protocol), protocol translation using the proper adapter, passing the translated message to the Integration engine, receiving of the processed target message from the Integration engine, translation of the XML-SOAP protocol to the receiver system's native protocol and transfer of the message to the receiver system. The Adapter framework is the basis of the Adapter engine. The Adapter framework is based on the J2EE engine and the J2EE Connector architecture (JCA). The adapter framework provides interfaces for configuration, management and monitoring of the adapters [4]. SAP PI incorporates several standard adapters and also allows installation of the 3 rd party adapters (Odette, VDA, RosettaNet, etc.). In dual stack system most of the standard adapters run in the Java stack, only two adapters run in ABAP stack. Java stack adapters: RFC adapter JDBC adapter SOAP adapter File/FTP adapter Mail adapter SAP Business Connector adapter 17

24 Marketplace adapter JMS adapter RNIF adapter CIDX adapter ABAP adapters IDoc adapter HTTP adapter The Java Adapter engine of SAP PI system in version 7.30, which is currently used within RIETER IT systems landscape, contains two brand new Java adapters, which are intended to replace the ABAP adapters in future: IDoc_AAE adapter HTTP_AAE adapter AAE is the abbreviation for the Advanced Adapter Engine. Those new adapters offer an extensive variety of the communication parameters, which are then fully under the control of the designer of an integration scenario. 4.5 Design and configuration tools The integration scenario, which holds all the configurations of the data exchange logic, comprises of several elements describing what and how the scenario will perform. The objects participating in a data exchange and the configuration of their relations and processes above them are maintained in two basic containers Enterprise Service Repository and Integration Directory. There are two main software tools which allow creation and maintenance of the design objects and the scenario configuration Enterprise Service Builder and Integration Builder. Both the tools run on Java and are accessible from the SAP PI system homepage. The homepage can be invoked from the standard SAP GUI using the transaction SXMB_IFR. The SAP PI system homepage is the starting point for all the tasks related to the system configuration, system management, system monitoring and the integration scenario design and configuration. 18

25 The following picture 8 shows the typical view of the SAP PI system homepage. Meaning of the links shown on the homepage will be closely described in the next chapters. Special attention should be paid to the item "System Landscape Directory" (SLD). SLD is the directory of all technical systems and software components in the system landscape. This directory helps system administrator/architect to manage and maintain components which are used within the company IT infrastructure in any manner. The systems and components contained in the SLD are used for configuration of the integration scenarios. The last tool which was not mentioned yet is the Runtime workbench. It can be used for monitoring of the system components and/or messages in the system. I use all the above mentioned tools in my daily work for the configuration of new and change of existing scenarios as well as for monitoring of the system and solving of data exchange problems. Picture 8: SAP PI system homepage 19

26 4.6 Enterprise Service Repository Enterprise Service Repository (ESR) is the component of the SAP PI system where the objects used later in the integration scenario are designed and created. The objects are created in the Enterprise Services Builder tool. Within this thesis I will describe in details two main categories of the objects used for data exchange: Interface objects Service interfaces Message types Data types Mapping objects Operation mapping Message mapping Another category of the design objects is External definitions, which groups the definitions of the message types or mapping programs created externally (for example message type defined by a WSDL document or Java mapping program created in an external Java development environment). The relations between the objects of each category are depicted in the following picture. Interface objects Mapping objects Service interface Operational mapping 1:1 relationship 1:n relationship Message type Message mapping 1:n relationship Data type Picture 9: ESR objects and relations 20

27 In addition to the design objects shown in the picture 9 the ESR can also accommodate the definitions of the external objects external message types (e.g. IDoc structures imported from SAP ECC), Java or XSLT mapping definitions, RFC message types, Web Services methods etc. The following picture displays the graphical user interface of the Enterprise Services Builder tool. Left hand side of the tool's window contains list of all design objects categorized by the software component to which the objects belong, namespace and by the object types. The right hand side of the window shows the object definition, in the case of picture 10 the displayed object is the Message mapping of the HR_OrgUnits message type. Picture 10: Enterprise Services Builder The standard sequence in which the design objects are created and configured during the integration scenario creation is: Import of the external definitions Creation of the data types Creation of the message types Creation of the service interfaces Creation of the message mappings Creation of the operation mappings 21

28 4.7 Integration directory Integration directory (ID) accommodates configurations of the steps of an integration scenario. It can be said, that if ESR contains the definition of the logic of the data exchange, ID contains the definition of the technical parameters of the data exchange. Generic integration scenario contains following components: Definition of the sender and the receiver systems Definition of the involved system's native protocols Sender and/or receiver agreements Interface determination Receiver determination The configurations are created in the software tool called Integration Builder whose graphical user interface is shown in the picture 11. Left hand side of the window contains list of all created configurations categorized by integration scenario name and category of the configuration. Right hand side of the window contains the details of a particular configuration, in the case of the picture 11 the displayed item is the definition of the integration scenario with the list of all the particular configurations. Picture 11: Integration Builder 22

29 4.8 Management and monitoring The basic tool for the system management and monitoring is the Runtime workbench. Runtime workbench allows monitoring and management of the system either on the communication component level or on the message level. In most cases the management is performed on the component level while the monitoring is performed on the message level. If a problem is found on the message level, then it usually means that something in the design or configuration of the integration scenario is not properly set and requires change either in ESR and or ID. Such an approach allows me to keep the system and the data exchange in the consistent state. I have to mention the ABAP stack part of the system management and configuration also. This part is valid for dual stack systems. As the implementation of the SAP PI system in RIETER IT system landscape is dual stack, I use ABAP stack management and monitoring daily. The basic monitoring tool in the ABAP stack is the Integration engine monitor (accessible via the transaction SXMB_MONI) and especially its part called Message monitoring. Alerting is also part of the monitoring tools in ABAP stack. It allows sending automated alert messages to the defined recipients in case of any data processing problem occurs. Most of the system management tasks can be performed in Integration engine administration, which is accessible via transaction SXMB_ADM. The disadvantage of the ABAP stack management and monitoring tools is that it only covers the Integration engine part, while the management and monitoring tools in Java stack cover the complete system (both Adapter and Integration engines). On the other hand the tools in ABAP stack are usually faster accessible from the SAP GUI. That's why I use both ABAP and Java tools. The following picture shows the Runtime workbench. The links in the upper side of the window represent various monitoring types (component level, message level). 23

30 Picture 12: SAP PI Runtime workbench 24

31 5 Data exchange process design and configuration This chapter describes the general process how objects and configurations of the integration scenarios are developed. The examples stated in this chapter are not related to any particular integration scenario, I have chosen examples which well demonstrate a particular design object or configuration, so they are chosen from various independent integration scenarios. All the example objects and configurations exist and are used in SAP PI system in the IT environment of RIETER. In the beginning of the integration scenario development I have to collect the business requirements regarding the content of the source and target data formats, meaning of the data (not in all cases) and the information about the process components and the systems involved in the data exchange. The necessary facts I need to know before I start to work on the integration scenario are: Source and target message format Requirements for the message content translation Protocols (communication technologies) used for source and target messages Sender and receiver systems If both systems are already created in the System Landscape Directory (see chapter 4.5) then I can start with the design of the objects, otherwise I have to create the entries for the systems in SLD. If a specific configuration or setting is needed in sender or receiver system (RFC destination for example), then I either configure the system by myself (SAP systems, Lotus Domino system) or ask the responsible person for the proper setting (3 rd party systems for example). Message content translation requirements are usually specified generically, the transcription of the requirements to an IT language is part of my work. In most cases the translation requirements are simple, but sometimes it requires quite complex Java or ABAP functions to translate or convert the content of particular fields of the message. 25

32 The definition of the source and target message format means the list and structure of the message data fields. There could be for example specific message header containing the sender system identification consisting of several fields, then the data part consisting of many data records structured in the specific format and the message footer. Message formats of IDocs and RFCs can be imported into SAP PI from the sender or the receiver system; the other message formats must be created manually in ESR or imported from prepared XSD or WSDL document. 5.1 Design objects Once the prerequisites mentioned in the previous paragraphs are met, I can start with the design of the objects used in the data exchange process. All the design objects are created using the Enterprise Services Builder tool. The design objects are grouped in the namespaces, the unique identification of an object comprises of namespace and object name. The namespaces are then grouped under software components, which represent either process components or group of process components. Software components are defined in SLD as parts of the business systems. The objects must be created in the natural sequence, starting from the elementary objects (Data types) to the complex objects (Operation mappings). This rule is not defined in the system itself; it simply follows the natural character of the design process Data types The data types are the basic elements of the whole data exchange process. They contain definition of the data record structures and types of the values of the particular fields and number of occurrences (in technical language: cardinality) of the fields in the structures. The elements of a data type are hierarchically structured and a data type can be used as a type of an element in another data type. The following picture 13 displays an example of a complex data type. Such a data type is a kind of top level type which is used for the definition of the message type. Please refer to the picture 9 in chapter 4.6 for an overview of the cardinality of the relations between data types and message types (it is always 1:1; that is why the data type must define the cardinality). 26

33 Picture 13: Complex data type definition Message types If the data types for all data records of both source and target messages are defined, then I can create the message types. The definition of a message type is very simple just assignment of a top level data type to a message type. The following picture 14 shows how a message type is defined. Picture 14: Message type definition 27

34 There is another category of message types apart from the message types defined manually in ESR the external (or imported) definitions. If sending or receiving system provides the description of the message structure in a standardized format (XSD, RFC or WSDL), then such a message can be created automatically based on the provided description and then used as an ordinary message type Service Interfaces Once the message types for the source and the target messages are created and/or imported I create the Service interfaces as shown in picture 15, which determine the direction of the messages flow (Category field). In the interface definition I also define if the communication will be synchronous or asynchronous (Mode field). Picture 15: Service interface (inbound) definition Please note, that apart from the message containing the business data the designer of the interface can also define Fault message type. Even in the asynchronous mode SAP PI offers the possibility to detect an error during the transmission of a message and react on the error. Fault message type is a special category of the design objects. Such a message type usually contains predefined system fields only. It is up to the designer of the integration 28

35 scenario to define handling of the fault messages (proper message mapping and delivery of the information about an error to the sending system) Message Mappings When all data types, message types and direction of the messages flow are defined then the most complicated part of the whole integration scenario can be defined the Message mapping. Although the message mapping definition is the most complicated part of the integration scenario design, it is also the most interesting part. The message mapping defines how the structure and the values of a source message will be mapped to the structure and values of a target message. The area of the mapping is quite wide and complex and detailed description of the available mapping techniques and technologies would significantly exceed the scope of this bachelor s thesis. I will only briefly describe the categories of the available mapping technologies and point out some interesting techniques, which I use in various integration scenarios. The message mapping is usually defined in the editor of the graphical mapping, which is part of the Enterprise Services Builder (see picture 16 for an example of the graphical mapping). The simplest method of mapping is copying of the values from the source message to the target message. Such a mapping does not perform any transformation of the values. If some fields from the source message do not have their counterparts in the target message, then such fields are omitted. In most cases the simple values copying does not fit the requirements of the data exchange. Then the more complex mapping techniques take place. Enterprise Services Builder offers a number of predefined mapping functions, which can be used in the graphical mapping. Some of the predefined functions are very simple (like conversion of all characters to upper case), some of them allow conditional mapping (if then) and some are really complex and allow advanced mapping using the lookup in the tables of an external system for example. The example shown on picture 16 demonstrates mapping of the UserID field of the source message to the IDOC node of the target message. 29

36 Picture 16: Example of the graphical mapping If the predefined functions are not enough to fulfil the requirements of the data exchange, then SAP PI allows the usage of so called User Defined Functions (UDF), which are pieces of Java code performing a particular operation on the input data and returning the result of an operation. Such UDFs are very handy and really easy to use. The code of an UDF is created directly in the Enterprise Services Builder and the UDFs are parts of a message mapping definition. Example of a simple UDF used for splitting of an XML node onto two nodes can be seen in picture 17. Picture 17: Example of the Java User Defined Function If even UDFs are not enough, then external Java, ABAP or XSLT mapping programs can be used. Since ABAP language will not be available in single stack systems, I actually have two options only. I decided to concentrate on Java technology in the first stage as Java is the integral part of the existing software platforms used in RIETER. XML based technologies are anyway of big imporatancy not only in the area of data exchange, but generally in IT and especially in the area of software development, which is my primary field of interest. The Java mapping programs used within an integration scenario are generally based on reading of the source data stream, manipulation of the data and writing the result to the 30

37 target data stream. Such a mapping program is created in an external Java development environment and then imported into the ESR as Java archive (JAR). If one of those mapping program is used, then the graphical mapping provided by Enterprise Services Builder cannot be used, the complete message mapping is performed based on the external mapping program. Picture 18 shows an example of the message mapping of the personal data sent from SAP HCM system (source message) and dedicated to Active Directory (target). Picture 18: Message mapping definition Operation Mappings The last design object which is part of each integration scenario is the operation mapping. The operation mapping incorporates all previously created objects and defines which message mapping will be used for which service interfaces. It is possible in general to have for example one outbound interface and several inbound interfaces with specific message mapping for each of them. Picture 19: Operation mapping definition 31

38 If one of the external mapping programs mentioned in the previous chapter are used, then they are assigned in the operation mapping (as can be seen in Mapping Program section in the example shown in the picture 19). 5.2 Configuration objects The design objects described in the previous chapter define the logic of the data exchange, while the configuration objects described further in this chapter define the technical aspects of the data exchange. All the configuration objects are created using the Integration Builder tool Configuration scenario Configuration scenario is just a container used for grouping of the rest of the configuration objects. It gives a quick overview of all objects involved in a particular integration scenario. The functionality of any configuration object does not depend on its membership in any configuration scenario and one configuration object can be a member of more than one (or even none) configuration scenario. The following picture 20 shows an example of the configuration scenario containing the configurations of one particular integration scenario. Picture 20: Configuration scenario definition I always create the configuration scenarios for each single receiver system, so that I can quickly find all configuration objects valid for a particular system in case of need Business system, Business component Business system and Business component objects are actually the same thing the representation of the process components involved in the integration scenario. The 32

39 difference between them is that while Business system is imported from the SLD, the Business component is created ad hoc manually in the Integration Builder Communication channel The communication channel is the key object of the whole technical configuration of the integration scenario. It defines which adapter will be used for the communication with a business system/component. Each adapter has its own set of configuration parameters. Picture 21 displays an example of the configuration of the File receiver adapter. Picture 21: Communication channel definition The definition of the communication channels can be compared to the definition of the message mappings in the sense of required knowledge and experiences. A developer of an integration scenario must have advanced knowledge about the system landscape, network technologies, communication protocols and their parameters, security and SAP system configuration. It is very often necessary to cooperate with the person responsible for the sending or receiving system so that the communication parameters can be properly defined Receiver determination The receiver determination is the core object of the integration scenario as it determines the target system of a message passing through the integration scenario. The receiver determination is a part of the Integration Directory, but uses also the design objects of the Enterprise Services Repository. 33

40 The determination of the receiving system is based on the source message. As stated in the chapter 4.3, the message structure and the direction of the communication define the service interface. That is why the receiver determination object uses the service interface as the input parameter and, if required, also the message content for the determination of the receiver. The following picture demonstrates how the receiving systems are determined based on the field value. The receiver determination displayed on picture 22 is one of those which are used in multiple configuration scenarios. Picture 22: Receiver determination definition. In case of a simple integration scenario involving just one sending and one receiving system the receiver determination does not contain any conditions, it just determines that a message connected to the specified interface is delivered to the specified system Interface determination Once the receiver is determined it must be also determined how the messages flowing from the sender to the receiver will be processed. This task is defined in the interface determination object. The interface determination works with the source message definition and determines which operation mapping defined in the ESR will be used for the message processing. 34

41 The operation mapping contains the definition of the inbound interface, so all necessary parameters are known after the interface determination is performed. The operation mapping which will be used can be determined either based on the value of a field (or fields) of the source message or simply assigned to the source message (in fact to the outbound interface) as shown on the following picture 23. Picture 23: Interface determination definition Up to now I did not get a request for an integration scenario, which would use more than one mapping for one combination of the source and the target messages, but if such a requirement will come, then the interface determination is the place, where I could define which mapping will be used based on the defined conditions Sender agreement The sender agreement defines binding between the sender system, outbound interface and the sender communication channel. Generally it is necessary to define the sender agreement for all communications where SAP PI system (particularly the Integration engine) is the target. It means that the sender agreement should be defined for all outbound interfaces which are in use. There is an exception for the communication based on IDoc, RFC or HTTP adapters. All those adapters are based on ABAP and the sender agreement is not necessary in those cases. Nevertheless the new IDoc_AAE and HTTP_AAE adapters, which are based on Java, require the sender agreement definition. Therefore I decided defining it for any sender system and adapter used as good practice according to SAP recommendation. 35

42 The following picture 24 shows the definition of the sender agreement used by 3 rd party sender system and using the file adapter (file sender communication channel). Picture 24: Sender agreement definition Receiver agreement The similar definition of the binding between a system, interface and an adapter as for the sender systems must be created for the receiver systems also. Such a definition is named receiver agreement. The receiver agreement contains definition of the combination of the receiver system, inbound interface and the adapter (communication channel) which will be used. In addition the receiver agreement also contains the identification of the sender system, so the information defined in the receiver agreement describes in fact the complete integration scenario. That s why I use the receiver agreement as the source of the WSDL document when creating the communication interfaces of the process components in 3 rd party systems. The picture 25 shows an example of such a receiver agreement. Picture 25: Receiver agreement definition 36

43 5.3 Summary of the typical components of an integration scenario The information contained in the previous chapters covers the complete set of the design objects and configurations needed for the implementation of the integration scenarios in SAP PI system. The following table contains summary of all previously described objects in brief. Table 1: Summary of the components of an integration scenario Enterprise Services Repository Data type Message type External definitions Service interface Message mapping Operation mapping Integration Directory Business system/component Communication channel Receiver determination Interface determination Sender agreement Receiver agreement 37

44 6 HR Data distribution With all the knowledge about the data exchange techniques, mediated communication concept, its implementation in SAP PI system, detailed architecture of the system and design and configuration objects of the data exchange scenario I can present the implementation of the particular integration scenarios intended for the distribution of the personal data from the SAP HCM system to other systems within the IT environment of RIETER. The personal data are created, updated and deleted exclusively in the SAP HCM system and used (read) in nearly all other systems used in the RIETER IT infrastructure. There are two exceptions in this single data source concept the information about person s e- mail address and telephone number has its source out of SAP HCM. address is delivered from the mail system and telephone number from the telephony system. Once those pieces of data are delivered to SAP HCM they become part of the complex personal data and they are distributed to other systems along with the rest of the personal information. In addition to the personal data the SAP HCM system delivers also information about the organizational structure of the whole company in order to deliver proper data in proper context. As each system, which uses the personal data, has its own demands regarding the content, structure and delivery format of the data, I have created several integration scenarios fulfilling the defined requirements. Those scenarios and the complex process of the HR data maintenance and distribution serve as appropriate demonstration of the capabilities and strengths of the SAP PI system implemented in the IT environment of RIETER. As the definition of the personal information, required by the involved consuming systems, does not correspond with any data structure which SAP HCM system can provide using its standard programs or function modules, I had to define the data structure covering all the requirements and selection criteria, which are used for data extraction. During this preparation phase I cooperated with colleagues from HR department in order to define correct selection criteria and with ABAP developer so that we agree on the data structure and on the method of the delivery of the extracted data records from SAP HCM system to SAP PI. 38

45 During the realization phase of the project the ABAP developer and me have decided, that we do not want to add any unnecessary logic to the definition of the integration scenario on SAP PI side. That is why the extraction program on SAP HCM side delivers the identification of the receiving system in the specific field, which is then used in the receiver determination object. The reason for this decision was variant requirements from the consuming systems regarding the selection criteria. Each system required different set of the personal records based on various conditions. We have decided that the selection will be performed in the source system and not during the message mapping in SAP PI system. The following picture 26 depicts the distribution of the personal data to the consuming systems. The objects named ROD and RPD represent the distributed data. ROD stands for Rieter Organizational Data and RPD stands for Rieter Personal Data. Such a naming indicates that the structure of the data is not of any kind of standard SAP data records. HCM SAP Systems ECC OM HRMD RPD PI ROD RPD ROD RPD TELNR RPD RPD RPD NAB Telephony system AD Access mngt. system IBM / LND Collabo ration LDAP Ticketing system Office Non-SAP Systems Picture 26: Distribution of the HR personal data 39

46 6.1 Involved systems The source system of the personal data is generally SAP HCM system (with the two exceptions mentioned in the previous chapter). There are several receiving systems consuming the HR personal data and using it for their own purposes. The following table contains an overview of the systems currently involved in the HR data distribution. I have added also column with the data format which each system provides or expects. Here the advantage of the mediated communication can be nicely seen there is one ABAP program for the data extraction (which would be needed anyway) and the complete data exchange is ensured by the standard adapters which are available in SAP PI Adapter engine. Table 2: Systems involved in the HR data distribution System Role Data format Note SAP HCM Sender/Receiver ABAP Proxy; IDoc Master system Lotus Domino Sender/Receiver SOAP Source of address Telephony system Sender Flat file Source of phone number SAP ECC Receiver RFC Active Directory Receiver Flat file Access mngt. system Receiver JDBC The ABAP Proxy technology was not mentioned yet. The ABAP Proxy is just a representation of a service interface, which is defined in SAP PI ESR. Such a Proxy is used by an ABAP program as the reference of the expected or delivered data structure. The communication itself is performed by RFC (using configured RFC destinations). 6.2 Process components The data exchange is an issue between two process components. In the particular case of the HR data distribution the process component can be either single ABAP program or single Lotus Domino database (or even more precisely one single WebService in one 40

47 particular database) or the complete Active Directory database. It always depends on the definition of the requirement. I, as the designer of the integration scenario, very often do not have any further information about the structure or functionality of the source or target systems. Generally I also do not know the exact purpose of the delivered data. Usually I get the requirement asking for delivery of the data with specified structure, in specified format to the specified location. In case of such a requirement I treat the complete sending or receiving system as the single process component within the integration scenario. If I am involved either in processes preceding the data delivery or in the further processing of the data after delivery, then I usually know the purpose of the data and also the particular components of either sending or receiving system. In such a case I usually treat the particular program, database or module as the process component in the integration scenario. The requirements for the HR data delivery resulted in the following table 3 of the process components: Table 3: Process components involved in the HR data distribution System Process component Role Type/category SAP HCM Z_HR_SND_ROD_RPD Sender ABAP program Lotus Domino MUA Sender Domino database Telephony system Avaya Sender System SAP HCM HRMD Receiver BAPI Lotus Domino RTB Receiver Domino database SAP ECC Z_HR_REC_RPD Receiver Function module MS Active Directory MS Active Directory Receiver System Access mngt. system KABA EXOS Receiver System In case of process components which are part of the Lotus Domino system I am also author of the modules used for processing of the outgoing (MUA database) or incoming (RTB database) data. Both the modules are based on the WebService technology. 41

48 6.3 Integration scenarios design and configuration When designing the complex scenario for the HR data distribution I decided to group the design objects (in ESR) into the several namespaces, one for each involved process component and then assign all those namespaces to one single software component which I named R_I_RIETER_SAP_HCM according to the naming convention valid in the SAP system landscape of RIETER. The configuration objects in ID are grouped to the configuration scenarios, one for each process component. Some configuration objects are then shared by multiple configuration scenarios of course. During the design and configuration phase I followed the process which I described in chapter 5. Gathering of the requirements Planning of the data structures Creation of the objects in SLD Configuration of the RFC destinations in SAP HCM and PI systems Creation of the design objects Creation of the configuration objects As the topic of this bachelor s thesis is the implementation of SAP PI system I will focus further in this chapter on the last two points mainly. Once the software component was created in SLD I was able to import it into the Enterprise Service Builder and start to create the design objects. The first step was the import of the external objects. According to the requests I determined that I will need to import one IDoc type for the update of the HR data with the values provided by foreign systems and one RFC definition which will be used for updating the HR information in SAP ECC systems (please refer to tables 2 and 3). During the design of the particular integration scenarios I have found, that I will need one more RFC definition, which I will use for the lookup into the HR master data. I imported following external objects: HRMD_A07 IDoc (imported from SAP HCM system) Z_HR_REC_RPD RFC (imported from SAP ECC system) HR_GETEMPLOYEEDATA_FROM USER (imported from SAP HCM, standard SAP function module) 42

49 The next step was creation of the namespaces, which will group the objects. I created following namespaces under the R_I_RIETER_SAP_HCM software component: urn:ri.hcm.data urn:ri.avaya.ri.hcm.data urn:ri.hcm.ri.ad.data urn:ri.hcm.ri.ecc.data urn:ri.hcm.ri.exos.data urn:ri.hcm.ri.rtb.data urn:ri.mua.ri.hcm.data After the creation of the structure of the complex scenario I was able to start with the design of the particular objects. The details of the prerequisites and parameters of the design objects is described in chapter 5, so I will briefly list the created objects and point out only interesting issues, which I met during the design phase. The namespace urn:ri.hcm.data contains the objects which are used for processing of the data coming from the SAP HCM system. This namespace contains the definition of the data type, which consists of all the fields used later in each particular scenario. That data type is used as the basis for the ABAP program sending the data from SAP HCM to SAP PI system. In fact I had to create one basic data type named Person containing all the HR data fields and then one complex data type named HCM_Personen containing header field for the receiver system identification and multiple occurrences of the Person data type. The definition of the complex data type HCM_Personen is displayed in the following picture, the complete definition in XSD format can be found in the Appendix A of this document. Picture 27: HCM_Personen data type definition 43