Migration Guide to AEX of PI 7.3x for Integration Scenarios

Transcription

1 Migration Guide to AEX of PI 7.3x for Integration Scenarios Applies to: SAP NetWeaver Process Integration 7.1x, PI 7.30, PI 7.31 SP2. Summary PI 7.30 introduced Advance Adapter Engine Extended (AEX), which is the java-only installation of PI. Without the ABAP stack during runtime, the message pipeline processing is handled by the java-only stack. With this new java pipeline processing, PI s Integration Directory configurations will also have to be changed. In the article, we will provide a guideline to help migrate the existing dual-stack integration scenarios to a java-only single-stack engine. Author: William Li Company: SAP Labs LLC Created on: 12 January 2012 Author Bio William Li is a member of the SAP NetWeaver Orchestration and Integration Team in SAP NetWeaver Solution Management. He has been with SAP since originally as a SAP America consultant, as a developer at SAPLabs and then as a SAP NetWearver RIG member focused on Process Integration. He joined SAP NetWeaver Solution Management in April of SAP AG 1

2 Table of Contents 1. Introduction Pre-Requisite Limitations What this document will not cover Migration Options Step-By-Step Direction Scenarios that cannot be migrated Scenarios requiring additional work before migration can begin How to start Using Directory API Report Program How to execute the program: FAQ Related Content PI 7.30: PI 7.31: Copyright SAP AG 2

3 1. Introduction SAP introduced the Advance Adapter Engine (AAE) in PI The AAE provides end-to-end message processing to be executed completely in the java-stack. This increases performance significantly since messages will no longer be passed back-and-forth between the ABAP and the java stacks. With this javaonly processing, a new configuration object is also introduced in the Integration Directory to configure the end-to-end scenarios. This new configuration object is Integrated Configuration Object, or ICO, and is used to configure the scenarios which will only be processed in the java-only engine. Even though PI 7.10 can process messages in the java-only engine, there are still dependencies on the ABAP stack, one of which is user management, which still uses tx:su01 of the ABAP stack. With PI 7.30, AEX was created. AEX, a java-only ESB, is built on AAE, but with all the ABAP dependencies removed. For example, user management is done by useradmin of the java stack. Because of the leaner hardware requirement and performance improvements, AEX became very attractive as an installation option. Note: The dual-stack installation continues to be available as an installation option. The architecture remains unchanged from the previous releases. The tools for design and configuration remain the same. Note: Please note the distinction between AAE and AEX. AAE: AAE is an adapter engine which provides message processing in the java-only stack. AAE is installed in both dual-stack and single-stack PI installations of PI 7.1 and above. AEX: AEX is a java-only installation of PI, which uses the AAE. With the first release of java-only PI 7.30 AEX, there are still some restrictions on the configuration of integration scenarios; therefore, those types of scenarios cannot be migrated from the dual-stack. With PI 7.31, some of those restrictions were further corrected, with functionalities in Java made compatible with those of the ABAP stack. But, still, there are scenarios with functionalities depending on the ABAP stack which cannot be migrated. It is the intent of this guide to identify and detail what can be migrated and what cannot be migrated. And, for those that can be migrated if additional work will be required. 1.1 Pre-Requisite With the tasks involved during the migration process, the following knowledge will be required: Integration Directory configuration with Receiver Determination, Interface Determination, Sender and Receiver Agreements, and Communication Channels. These configurations are what we will call as classical configuration, and will be processed by both ABAP and java engines. Integration Directory configuration using Integrated Configuration Object (ICO). ICO is used to configure integrations using AAE. These integrations will only be processed by the java engine. 1.2 Limitations Since AEX is based on AAE, therefore, we should examine the limitations of AAE at each release level. This will allow us to understand what needs to be done during the migration process. PI 7.1x AAE Limitations in ICO IDoc adapter: IDoc adapter is only based in ABAP. Therefore, AAE cannot use the IDoc adapter. HTTP adapter: HTTP adapter is only based in ABAP. Therefore, AAE cannot use the HTTP adapter. WS adapter: WS is an ABAP adapter, based in ABAP, used for processing of WS-RM messages. There is no equivalent java WS adapter. Therefore, AAE cannot use the WS adapter. ccbpm: ccbpm uses ABAP s work-flow engine to orchestrate the messages 2008 SAP AG 3

4 between different systems and applications. ccbpm is not available for AAE. Extended Receiver Determination: Using operations mapping for dynamic routing of messages is not available. (Note: Routing based on XPath expression is available.) Receiver Rules: Using Integration Directory s Receiver Rule is not available. Dynamic Routing for Receiver Interface (the equivalent in Interface Determination): XPath and using of multi-mapping for dynamic routing is not available. Parameterized Mapping: Using mapping parameters in Operations Mapping is not available. ABAP Mapping: ABAP mapping is executed in ABAP, therefore, cannot be used by AAE. PI 7.30 AAE Limitations in ICO Java IDoc adapter: About 80% functionally complete when compared to the ABAP IDoc adapter. In many situations, this will not matter since the missing 20% may not be needed. WS adapter: WS is an ABAP adapter, based in ABAP, used for processing of WS-RM messages. There is no equivalent java WS adapter. Therefore, AAE cannot use the WS adapter. ccbpm: ccbpm uses ABAP s work-flow engine to orchestrate the messages between different systems and applications. ccbpm is not available in AAE. Extended Receiver Determination (the equivalent in Interface Determination): Using operations mapping for dynamic routing of messages is not available. (Note: Routing based on XPath expression is available.) Receiver Rules: Using Integration Directory s Receiver Rule is not available. Parameterized Mapping: Using mapping parameters in Operations Mapping is not available. ABAP Mapping: ABAP mapping is executed in ABAP, therefore, cannot be used by AAE. PI 7.31 SP2 AAE Limitations in ICO WS adapter: WS is an ABAP adapter used for processing of WS-RM messages. There is no equivalent java WS adapter. Therefore, AAE cannot use the WS adapter. ccbpm: ccbpm uses ABAP s work-flow engine to orchestrate the messages between different systems and applications. ccbpm is not available in AAE. Extended Receiver Determination: Using operations mapping for dynamic routing of messages is not available. (Note: Routing based on XPath expression is available.) Receiver Rules: Using Integration Directory s Receiver Rule is not available. ABAP Mapping: ABAP mapping is executed in ABAP, therefore, cannot be used by AAE SAP AG 4

5 Below is a chart summarizing the AAE limitations of the different PI releases: Feature PI 7.1x PI 7.30 PI 7.31 IDoc Adapter HTTP Adapter WS Adapter ccbpm Extended Receiver Determination Receiver Rule Dynamic Routing for Receiver Interfaces Parameterized Mapping ABAP Mapping 80% functionally complete when compared to the ABAP IDoc adapter 1.3 What this document will not cover This document will only discuss the migration of the Integration Directory objects from PI 7.1x to PI 7.3x. The design objects in the Enterprise Service Repository remain unchanged between the releases, therefore, will not be covered. Topics involving the migration from ccbpm to NW BPM is too complex to address here, and must be examined on a case-by-case basis. Alerting, which is a critical component during the migration process, is also not discussed in this document. Alert configurations have been addressed in other documents, which are listed in the appendix s Related Content. 1.4 Migration Options Knowing the AAE limitations of the different releases, we should be able to determine whether migration of a certain integration scenario would be possible. Migration, in this case, is defined as the re-configuration of the existing classical configuration to ICO. Classical configuration is based on Receiver Determination with Receiver and Sender Agreements. ICO is a new configuration tool introduced in PI 7.1 specifically used for AAE to process messages through the java engine only. Migration options: Migrate scenarios on the existing PI 7.1x system. o The advantage is that this will allow the start of the migration process without having a PI 7.3x system installed. o Migration will have to be restricted to the scenarios without the AAE limitations. o Afterward, the migrated scenarios can be exported to the PI 7.3x system when the system is available SAP AG 5

6 Upgrade, in-place, the existing PI 7.1x system to PI 7.3x. o The PI 7.3x system must be a dual-stack system, o After upgrade, all scenarios in the Integration Directory will still exist in the upgraded PI 7.3x system. o Migrate the classical configurations to ICO. o The advantage is that the normal PI upgrade process can be executed, with integration scenario migration to AAE on a less time-sensitive schedule. Install a separate PI 7.3x system. o The PI 7.3x system can be either a dual-stack or a java-only (AEX) system. o Migrate the scenarios one at a time, from PI 7.1x to PI 7.3x. o If the system is PI 7.31 AEX, then Process Orchestration, a bundled BPM, BRM, PI system, can be installed to help with the migration of ccbpm to NW BPM. 2. Step-By-Step Direction Because of the AAE limitations, there are some additional work during the migration process: The java IDoc, HTTP and XI (or proxy) communication channels will have to be created first to replace the existing IDoc, HTTP and XI communication channels. ( XI communication channel can be replaced by the SOAP adapter). Classical configurations using IDoc, HTTP and ABAP proxy may not be immediately identifiable. These scenarios may not have sender communication channels and sender agreements. ccbpm as sender or receiver may not be obvious, because no sender/receiver agreements or communication channels are required. Using the AAE limitations, we can construct a checklist. With this checklist we can determine the amount of work required and the best migration option. The checklist should contain: Scenarios that cannot be migrated due to dependencies on the ABAP engine. Scenarios that can be migrated, but only after some preliminary work is done, e.g. configure an IDoc_AAE java adapter to replace the existing IDoc ABAP adapter. Scenarios that can be migrated immediately. 2.1 Scenarios that cannot be migrated Based on the AAE limitations scenarios, the following features cannot be migrated, due to mostly dependencies on the ABAP stack: ccbpm WS adapter Extended Receiver Determination (this feature will be available at a later SP in PI 7.31) Receiver Rule (this is a fairly new feature with few usages) ABAP Mapping (To PI 7.30 only, okay for PI 7.31) Parameterized Mapping 2.2 Scenarios requiring additional work before migration can begin Due to changes required because the ABAP stack is no longer available, scenarios requiring the following features will need some additional work before migration from classical to Integrated Configuration can take place: IDoc adapter: java IDoc_AAE communication channels will have to be created. HTTP adapter: java HTTP_AAE communication channels will have to be created. XI adapter: SOAP communication channels will have to be created. Configuration changes in SM59 will also have to be done on the ABAP stack of the sending SAP system SAP AG 6

7 2.3 How to start All integration scenarios in the classical configuration must have a Receiver Determination. We can get a list in the Integration Directory: Identifying ccbpm scenarios, the Where-Used List can be used: The Receiver Determination in the Where-Used List cannot be migrated. Identifying scenarios using the WS adapter. a. Use the Find.. in the menu to find the WS communication channels SAP AG 7

8 The search criteria can be based on the communication channel name. b. Use Where-Used List : c. The Where-Used List will display Sender or Receiver Agreements. Additional searches will have to be performed to obtain the Receiver Determination. The subsequent steps are similar. Extended Receiver Determination usage: Extended Receiver Determination will have the following configuration. Unfortunately, there are no short-cuts to find which Receive Determination is using it SAP AG 8

9 Identifying Receiver Rule. Use the Where-Used List to find the Receiver Determinations. It is very possible there is no Receiver Rules defined, as in the case here: Identifying Receiver Determinations without Sender Agreements. IDoc, HTTP and XI adapters are based in ABAP. Messages sent from ABAP do not require Sender Agreements, therefore, no communication channels would be needed. When migrating to AAE, these communication channels will have to be created. There are no short-cuts to identify which Receiver Determination does not have a Sender Agreement except by going into the configuration: 2008 SAP AG 9

10 To identify which adapter is used will have to depend on the context, e.g. the namespace for IDoc is urn:sap-com:document:sap:idoc:messages. Consequently, a knowledgeable PI developer will be needed to go through these evaluations. 3. Using Directory API As one can see, the manual process of determining whether a Receiver Determination can be migrated and going through the tasks involved in the migration process can be quite time-consuming, especially when the number of Receiver Determination goes beyond 50. Directory API is ideally suited for this task. Using Directory API, we can perform the following: Get a list of all the Receiver Determinations. Get a list of all the Receiver Determinations with ccbpms dependencies. Determine the completeness of the Receiver Determination. Incomplete configurations need to be examined for migration possibilities. Determine whether Sender Agreement is missing. This will identify those scenarios requiring additional work, e.g. creation of IDoc_AAE communication channel. Determine the adapters used in the scenario, to identify IDoc, HTTP, XI and WS communication channels. This will let us know whether additional work will be required to create communication channels and whether the scenario can be migrated, as in the case of WS adapter. Determine whether Extended Receiver Determination is used. Determine whether parameterized mapping is used. A report might look like the following: 1 P71_020 Consumer_NoAuth_Out_Sync ** Sender WS Adapter ** Receiver WS Adapter Sender Comm Chan(WS) = * P71_020 WS_NoAuth_Sender Receiver = P71_010 - Provider_NoAuth_In_sync Receiver Comm Chan(WS) = * P71_010 WS_NoAuth_Receiver 2 ztest1_bpm req_sync_abs ** Sender is ccbpm + No Sender Agreement 2008 SAP AG 10

11 Receiver = ERP_EH3_800 - STFC_CONNECTION urn:sap-com:document:sap:rfc:functions Receiver Comm Chan(RFC) = * ERP_EH3_800 R_RFC 3 MD1_99 MD1 DEBMDM.DEBMDM06 urn:sap-com:document:sap:idoc:messages + Receiver IDoc Adapter Sender Comm Chan(MDM) = MD1_99 MD1 cc_mdm_adapter Receiver = EH3_99 ERP_EH3_800 - DEBMAS.DEBMAS06 urn:sap-com:document:sap:idoc:messages Receiver Comm Chan(IDoc) = EH3_99 ERP_EH3_800 cc_idoc_receiver Receiver = EH3_99 ERP_EH3_800 - ADRMAS.ADRMAS03 urn:sap-com:document:sap:idoc:messages Receiver Comm Chan(IDoc) = EH3_99 ERP_EH3_800 cc_idoc_receiver In the report, all the Receiver Determinations are displayed. A ** denotes an ABAP dependency that cannot be migrated. A + indicates that additional work may have to be done, therefore, a manual examination will be require. Receiver component and interface are displayed, along with the sender and receiver communication channels. Those Receiver Determinations without any annotations can be migrated without any problem. 3.1 Report Program A java program is available to produce such a report. The program can be downloaded from the following URL: Note: If the downloaded file has an extension of.zip, please change it to.jar. The program is contained in a jar file; therefore a java SDK will be needed. Java SE 1.6 is recommended. Disclaimer: The free software programs provided here may be freely distributed, provided that the disclaimer below is always attached to it. The jar file name is: pi71migration.jar The programs are provided as is without any guarantees or warranty. Although the author has attempted to find and correct any bugs in the free software program, the author is not responsible for any damage or losses of any kind caused by the use or misuse of the program. This is a read-only program and will not make changes to any of the existing configurations. The author is under no obligation to provide support, service, corrections, or upgrades to the free software program. This program does not capture 100% of the information due to the amount of variations and varieties that can be configured How to execute the program: java -cp pi71migration.jar com.migration.pi71.main.report host_port username password host_port = hostname:port of PI 7.1x server username = a valid username on the PI server password = valid password for username Username must have authorizations for PI configuration plus the following roles: SAP_XI_API_DEVELOP_J2EE SAP_XI_API_DISPLAY_J2EE The roles can only be assigned using 'useradmin' in Java. The roles are not available in SU01 of ABAP. Example command line to create the report: java -cp pi71migration.jar com.migration.pi71.main.report p71server:50000 demouser abcd1234 > report.txt You can redirect the output to a file. The output is tab-delimited, which can be opened with Excel for better viewing. Below is an example of a report opened with Excel: 2008 SAP AG 11

12 2008 SAP AG 12

13 FAQ 1. What are the main tasks involved during the migration when looking at the report: a. Determine which interfaces cannot be migrated, as denoted by **. They are the interfaces with ccbpm and WS adapter, and depending on the PI release, other criteria might also prevent migration. Please reference section 1.2 on Limitations. b. The Receiver Determinations with + will have to be manually examined. These interfaces can probably be migrated, but some additional preparation work will have to be done. Please reference the next 2 questions below. c. Receiver Determinations without ** or + can be migrated without any problem. You will need to delete the Sender Agreement for the interface, if it is on the same server, and configure an ICO which does the same as the Receiver Determination. 2. What does it mean when there is no sender or receiver agreement: The reason that there is no sender or receiver agreement is because there is no sender or receiver communication channels assigned to the Receiver Determination. Integrations using ABAP adapters do not require communications channels. This means that if you are using IDoc, HTTP or ABAP proxies, no communication channel is required. In this case, you will have to manually examine your interfaces to determine which adapters are being used. Based on that, you will need to create a java communication channel for that adapter. Then, ICO can be used to configure the scenario. 3. What does it mean when there is no interface determination: It means that the sender interface is the same as the receiver interface and no mapping is used. There is probably no additional work needs to be done to proceed with ICO configuration, a manual examination to verify would be a good practice SAP AG 13

14 Related Content PI 7.30: SAP NetWeaver Process Integration SAP Help - PI 7.30 Advanced Adapter Engine Message Alerting for SAP NetWeaver PI Advanced Adapter Engine Extended How to Set Up the Communication between ABAP Backend and SOAP Adapter using XI Protocol Upgrade Master Guide for SAP NetWeaver 7.3 PI 7.31: What is new in SAP NetWeaver PI 7.3 EHP1 SAP Help PI 7.31 Advanced Adapter Engine t.htm SAP Help PI 7.31 Component-Based Message Alerting SAP AG 14

15 Copyright Copyright 2012 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iseries, pseries, xseries, zseries, eserver, z/vm, z/os, i5/os, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty SAP AG 15