Java Development within the SAP Process Orchestration Platform

[Former Member]

Java Development within the SAP Process Orchestration Platform

Introduction: The stability, robustness and capabilities of the SAP process orchestration makes it increasingly a platform of choice as an ESB, BPM, BRM and composite service platform. More so, this is made possible with the toolset and infrastructure provided by SAP. These tools include; Java Only installation for PI, NetWeaver Development Infrastructure (NWDI), NetWeaver Developer Studio (NWDS), JEE Application server. In this blog, I will highlight some custom java development use cases that underscores the power of the SAP Process Orchestration Platform. Subsequent blogs will provide details on how to achieve these use cases within SAP PO. The custom Java development use cases to be considered include;

1. Process Orchestration with Java proxies
2. Custom mapping functions in BPM with EJBs
3. Java Mappings in PO operation mappings
4. Creating Adapter Modules with EJBs

Tools, Infrastructure Needed:  Certain essential tools within a specific infrastructure is needed to implement some of the use cases mentioned above, they include;

1. SAP Process Orchestration Java Only installation
2. NetWeaver Developer Infrastructure (NWDI)-optional
3. NetWeaver Developer Studio

Case 1: Process Orchestration with Java Proxies: Java Development with java proxies on the SAP PO platform comes handy in use cases where system-to-system orchestration needs to be implemented, especially for synchronous calls. However, when system-human interaction orchestration is necessary, then SAP BPM becomes the implementation method of choice. The use of java proxies has its pros and cons;

Pros: Better performance for system-to-system orchestration, leverages the AS Java infrastructure provided by SAP, desirable and comprehensive integration logic can be built in Java.

Cons: Availability of Developers/Architects with good Java knowledge is essential, Troubleshooting can be a difficult task

There are two flavors of Java proxies that can be developed in NWDS for building orchestration logic; the client java proxy and server java proxy.

a) Java Client Proxy: The Java client proxy is developed as the client application that consumes the Integrated Configuration (ICO) created in the Integration Directory. To develop a client proxy, a number of steps need to be implemented, these are described in high level here; 1) Create a development component of type EJB (from development infrastructure perspective) 2) Create a development component of type EAR (from development infrastructure perspective) and add the EJB dc created earlier as a dependency 3) add necessary SAP standard component (engine.jee5.facade, tc/esi/esp/wsrm/facade) as dependencies 4) Import a WSDL (file system) or a modelled outbound service interface (from ESR). 5) Generate a webservice client on the WSDL/service

6) Create a wrapper class to implement the bunch of classes generated in step 4. This is done by creating a session bean with a local interface, the session bean implementing class contains the logic to call the port and pass the request into the ICO. 7) Build the EAR and EJB dcs, then deploy the EAR file on the AS Java. 😎 Go to the NetWeaver Administrator and configure the client proxy to consume the ICO. Within the NWAèSOAèApplication and Scenario CommunicationèSingle Service AdministrationèConsumer Proxies (search for the name of the WSDL/service interface on which the client proxy classes were created). Navigate to the “Configuration tab”, with the option “New” follow the wizard to configure consumption of the ICO (use the import from WSDL URL) option to import the WSDL of the ICO from the integration directory as well the endpoint. Follow the wizard and complete the configuration.

b) Java Server Proxy: The Java server proxy is developed as the service provider where the integration logic that drives the orchestration is developed. Integration logic capabilities that can be developed include; calling the client proxy EJBs, data transformation (mapping functionalities) or request and response data. To develop a server proxy, a number of high level steps are implemented; 1) Create a development component of type EJB (from development infrastructure perspective) 2) Create a development component of type EAR (from development infrastructure perspective) and add the EJB dc created earlier as a dependency 3) add necessary SAP standard component (engine.jee5.facade, tc/bl/logging/api, tc/je/webservices/api) and client proxy dcs as dependencies 4) Import a WSDL (file system) or a modelled inbound service interface (from ESR). 5) Generate a webservice Java Bean Skeleton on the WSDL/service

5) Develop the logic within the created “implementation bean class”. To be able to create annotations on the local interfaces of the client EJBs, the client classes must be exposed in the “public parts”  7) Build the EAR and EJB dcs, then deploy the EAR file on the AS Java system. 😎 Go to the NetWeaver Administrator and configure the client proxy to consume the ICO. Within the NWAèSOAèApplication and Scenario CommunicationèSingle Service Administrationè Service Definitions (search for the name of the WSDL/service interface on which the server proxy classes were created). Navigate to the “Configuration tab”, with the option “New” follow the wizard to generate a new WSDL that will be used as the entry point into this service. Follow the wizard and complete the configuration. The WSDL URL can be used in the receiver channel configuration in the Directory.

N:B- The Sender channel for the ICO to be consumed by the client proxy is of type SOAP, also the receiver channel used in the ICO that calls the server proxy is also of type SOAP. However asynchronous calls, SOAP Sender channel with XI.30 message protocol can also be used for WS-RM. This also has to be stated during the configuration of the client proxy in NWA.

Case 2: Custom mapping functions in BPM with EJBs :  Often complex data transformations between two steps in the process flow of BPM becomes essential. In situations where basic mapping is not enough within the expression editor and also where operation mapping from the ESR cannot be imported for use, creating an EJB function becomes an alternative. To create an EJB for mapping use within the BPM, perform the following steps; 1) Create a development component of type EJB (from development infrastructure perspective) 2) Create a development component of type EAR (from development infrastructure perspective) and add the EJB dc created earlier as a dependency 3) add necessary SAP standard component (engine.jee5.facade, tc/bl/logging/api, tc/bpem/mapping/façade, /api, tc/je/sdo21/api) as dependencies 4) Create a session bean with a local interface, the local interface extends the “function” and “Sdo” SAP standard classes. Implement the session bean class to invoke the data object, perform the necessary mapping transformations and set the output back into the process 5) Deploy the EAR file of the ejb to the AS Java. 6) Navigate to the JNDI tree browser and search for the deployed ear, the JNDI via which this object can be located at runtime can be seen. 7) Create a mapping function artifacts  with the process development dc, configure the mapping artifact with input and output parameters as well as reference to the JNDI name of the deployed EAR file.8) Use the custom mapping from the expression editor.

Case 3: Java Mappings in PO operation mappings: SAP PI/PO provides different mapping possibilities to achieve transformation from the source message structure to the target message structure. Graphical mapping is often the first choice, but when graphical mapping is unable to achieve the mapping functionality, then XSLT mapping can be of irrelevance. However, implementing a Java mapping within PO might be the best option. The steps necessary to implement a Java mapping are highlighted here;

1. Create a Java project in Eclipse or NWDS, thereafter create the rest of the necessary artifacts vis-à-vis package, class
2. Add the necessary SAP jar files needed as dependencies to the project
3. Implement the logic for the mapping within the Java Class
4. Export the java class as a jar file to a local directory
5. Create an Imported Archive object in the ESR
6. Import the jar file into the Imported Archive object
7. Select the java mapping jar file within the Operation Mapping

Case 4: Creating Adapter Modules with EJBs: In order to extend the functionalities of the SAP standard adapters (file, JMS, SOAP) during message processing, it is possible to create adapter modules with java classes. To create an adapter module, the following high level steps should be implemented;

1) Create a development component of type EJB (from development infrastructure perspective) 2) Create a development component of type EAR (from development infrastructure perspective) and add the EJB dc created earlier as a dependency 3) add necessary SAP standard component (engine.jee5.facade) and client proxy dcs as dependencies 4) Create a session bean and implement the necessary logic for the adapter module. 5) Define the JNDI name within the “ejb-j2ee-engine.xml” file as well as the EJB name within the “ejb-jar.xml” file. These names must be unique in order to avoid naming conflicts and the class loader loading a different bean than expected. 6) Build and deploy the EAR file, configure the communication channel with the adapter module based on the JNDI name.

Conclusion: In this first blog, I have highlighted a number of custom java developments that can be achieved by leveraging the SAP PO Platform. These blog series aims to help putting the essential possibilities into perspective for SAP PO consultants, Developers, Solution Architects and Enterprise Integration consultants. They can adopt these, to realize certain process integration/orchestration requirements within projects. It also aims to help tick the checklist box of essential skills set to consider when working with the SAP PO platform. Detailed step by step guide on how to realize these use cases will be discussed in my subsequent blogs.