SAP has decided to strategically move into the Java world for SAP NetWeaver Process Integration (SAP NetWeaver PI). This move was proven by the first Java-only deployment option of SAP NetWeaver PI called Advanced Adapter Engine Extended (AEX). For more information about AEX, see the introductory article “SAP NetWeaver 7.3 AEX: A New Installation Option for SAP NetWeaver PI” by Elke Doering and Peter Gutsche.

With the latest offering, SAP NetWeaver Process Orchestration 7.31, which is in essence a combined installation of SAP NetWeaver Business Process Management (SAP NetWeaver BPM), SAP NetWeaver Business Rules Management (SAP NetWeaver BRM), and the AEX on one Java Virtual Machine (JVM), the next step was done: The functionality of the modeling and configuration tools moved as dedicated perspectives into SAP NetWeaver Developer Studio. Consequently, there will be no further investments in new functionalities for the two Swing clients called Enterprise Services Builder and Integration Builder.

Whereas the Enterprise Services Builder functionality was already addressed in the Enterprise Services Repository perspective (ESR perspective) in SAP NetWeaver Developer Studio, the Integration Builder functionality is now covered with SAP NetWeaver Process Orchestration 7.31 as a new SAP NetWeaver Development Studio perspective in the Process Integration Designer (PI Designer). To show what is already covered in the new perspectives, I will guide you through a complete integration scenario and how it is built from scratch using only the SAP NetWeaver Developer Studio-based tools. As you follow the steps in this scenario, you experience a new modeling and configuration approach for message handling in the AEX. In this installment I will concentrate solely on the ESR perspective.

For more information about SAP NetWeaver Process Orchestration, take a look at my previous article, "Solve Business Process Implementation and Integration Problems with SAP NetWeaver Process Orchestration." 

Let’s get started. The guide for this implementation project is the process model depicted in Figure 1.

It shows the participating communication parties in the boxes on the left and right named Sender System and Receiver System, respectively. The message handling within the integration engine itself is symbolized by the box in the middle carrying the name iFlow_Sender_to_Receiver. The name already indicates the new configuration object that will be maintained by the new PI Designer perspective — it’s the integration flow (iFlow).

Obviously, the sender system drops a message with the service interface name Customer_Out_Service via the SOAP adapter to the iFlow. As the interface name already indicates, it carries information about a customer. The SOAP adapter is named SOAP_S_Customer. The sending character of the adapter is expressed by the letter S in the adapter’s name. Once the message reaches the iFlow, it is mapped to the target service interface named Customer_In_Service. Via the file adapter, the resulting message is dropped on the receiver system’s side. The letter R in the file adapter’s name represents the receiving character of the adapter. To implement the scenario, you have to execute the following modeling and configuration steps:

1. Model the outbound service interface Customer_Out_Service in the ESR
2. Model the inbound service interface Customer_In_Service in the ESR
3. Model the mapping between the two interfaces in the ESR
4. Model the integration flow in the Integration Directory
5. Configure the complete scenario in the Integration Directory
6. Run the integration scenario

In this article, I will focus on steps 1 to 3.

Step 1. Model the Outbound Service Interface Customer_Out_Service

Start SAP NetWeaver Developer Studio and open the ESR perspective by choosing Window > Open Perspective > Other… from the main menu. In the Open Perspective dialog, choose Enterprise Services Repository and click OK. Once the perspective has been opened, connect to the ESR on the server side. This indicates that the ESR perspective is just a new UI to the server parts of the ESR. The behavior of the ESR itself did not change with the new perspective. Click the connect to ESR icon  to initiate the connection (Figure 2).

Figure 2

Connect to the ESR

You can connect to any ESR that is reachable from SAP NetWeaver Developer Studio via your network. You just have to maintain the appropriate ESR settings on the Preferences page of SAP NetWeaver Developer Studio. Click Windows > Preferences to open it and choose Web Services > Enterprise Service Browser to adjust the ESR configuration.

As soon as the connection to the ESR is established, you are asked for credentials to log in. Provide the appropriate data and after a successful log-in, the available software component versions are listed (Figure 3).

Figure 3

Software component versions in the ESR

Now you are ready to model the needed data types. Expand a software component version and the namespace in which you want to place your new scenario. Right-click the Data Types node and choose New Data Type from the context menu (Figure 4).

Figure 4

Create a new data type

The Create Data Type dialog opens. Enter an appropriate name (e.g., CustomerSender because you want to exchange customer information) and click Finish. A new dialog opens asking for a change list. This is also a reminder that you are connected remotely to the ESR. In the ESR, all changes are tracked as part of a change list. I haven’t defined one yet, so the dialog is now asking for a change list name. Click the New… button to type in a name such as DemoCL and click OK. The newly created change list is used for all new artifacts that are created in this example. However, from now on I do not explicitly mention adding each new artifact to the change list.

The editor for defining the fields of the data type opens (Figure 5). On the left side the data type’s name is shown, and on the right, the details of the type are listed. To add a new field to the data type, right-click its name on the left and choose Add Element from the context menu. You could also select the name and click the Add Element button.

Figure 5

Add an element to a data type

Regardless of the way you’ve added a new element, a new node appears beneath the data type’s name with a default name called Element1. You can overwrite the default name with something more meaningful in the Name field of the Details section (Figure 6). In this case, name your new element Firstname.

Figure 6

Rename the new field

Finally, assign an appropriate type to that field. Click the Browse… button residing behind the Type input field to open the Select type dialog. The dialog lists all available types of the ESR. You can narrow down the search by entering an appropriate string in the edit field at the top of the dialog (Figure 7). You want to assign the string data type to the field, so enter str in the field. All types are filtered for names starting with the given substring. Obviously, only the string type fulfills the search.

Figure 7

Select a type for the new element

Select the string type and click OK to assign the chosen data type to the Firstname field. The final result is shown in Figure 8.

Figure 8

Successful definition of the first element for the CustomerSender data type

Now add a second element to the CustomerSender data type and name it Lastname, which also should be of type string. The final result is shown in Figure 9. Save your changes.

Figure 9

Final appearance of the CustomerSender data type

Create a second data type representing the receiver’s data structure and name it CustomerReceiver. It should contain only one element of type string named Fullname, which implies a mapping that has to be created so you can concatenate the two fields of the sender data type to the single field of the receiver data type. The CustomerReceiver type is shown in Figure 10.

Figure 10

The CustomerReceiver data type

Now that the data types are in place, creating the associated service interfaces is straightforward. In the former Enterprise Services Builder Swing client, you had to create a message type before you were able to create the associated service interface. This step is not necessary any longer as during the creation of the service interface in SAP NetWeaver Developer Studio the message type is automatically created for you.

Right-click the Service Interfaces node in the Enterprise Service Browser window as you did for the data type (Figure 4) and choose New Service Interface from the context menu. The Create Service Interface dialog opens asking you for a service interface name. Start with the outgoing message and name it Customer_Out_Service. A new tab opens in the main window allowing you to maintain the service interface’s properties. In the Advanced section, change the Category drop-down list to Outbound as this interface represents a message being sent from the sender system (the direction is outbound). You receive a warning making you aware of possible inconsistencies the change to Outbound may cause, but you can ignore it as the warning only makes sense if the interface is already in use in other scenarios or if proxies have been generated for it. The final result is shown in Figure 11.

Figure 11

The Customer_Out_Service interface

So far, you haven’t defined the operation of the service interface. By default one operation is always automatically created for the service interface. You can find it in the Operations section (Figure 11). Click the link to define the associated message in the Service Interface Definition screen (Figure 12).

Figure 12

Define the message for the operation

Right-click the Input node and choose Add Input Message from the context menu. On the right side of the screen a Details section appears that allows you to assign an appropriate message type. Click the Browse button to select the data and message types (Figure 13). The Select Message Type dialog opens (Figure 14).

Figure 13

The Details section

Figure 14

The Select Message Type dialog

Select the data type for the sender (CustomerSender) that you created before and click Next. The wizard displays all message types that are associated with the chosen data type. Because you haven’t defined a message type, the list is empty (Figure 15). However, as I promised, you can now create the message type on the fly by clicking the Create Message Type… button.

Figure 15

Create a new message type

A new dialog opens asking for an appropriate name. Enter a name (e.g., CustomerSender_MT) and click Finish. The data type CustomerSender is automatically associated with this message type, so you cannot make errors that were possible with the old Swing-based UI. The newly created message type is automatically assigned to the service interface operation on which you are currently working. Click Finish again to exit the wizard and save. The final result is shown in Figure 16.

Figure 16

The final service interface definition of the sender

Step 2. Model the Inbound Service Interface Customer_In_Service in the ESR

Repeat the steps for creating a service interface for the receiver. Name the service interface Customer_In_Service. Make sure that the Category in the Advanced Section is set to Inbound as this interface represents a message that the receiver system receives; hence, the direction is inbound. When you are assigning the message type, create a new one named CustomerReceiver_MT and double-check that it is associated with the CustomerReceiver data type. Your final result should look similar to the one shown in Figure 17.

Figure 17

The final service interface definition of the receiver

You have now finished defining the interfaces. You can continue with the mapping exercise.

Step 3. Model the Mapping Between the Two Interfaces

You’re working with two interfaces that are not compatible with each other. Therefore, you have to define a mapping between the two. The message mapping and the operation mapping are now covered in SAP NetWeaver Developer Studio as well. Right-click the Message Mappings node in the Enterprise Service Browser on the left (similar to what you did in Figure 4 for the data type) and select New Message Mapping from the context menu. In the Create Message Mapping dialog, enter a name for the mapping. Enter a meaningful name such as CustomerOut_to_CustomerIn_MM and click Finish. In the window’s main area, a new tab opens that summarizes the settings of the message mapping. Most important, you have to define the two messages that have to be mapped in the Signature area of the screen (Figure 18).

Figure 18

Define the messages for the message mapping

Click the Add button of the respective subsection and select the messages you want to map. In this case, the source message is named CustomerSender_MT, and the target message is CustomerReceiver_MT. After you have chosen the message, your final result should look like the one shown in Figure 19.

Figure 19

Select Source Messages and Target Messages

Now you can map the fields of the source message to the respective fields of the target message. Switch to the Definition tab at the bottom of the message mapping window. The message mapping environment in SAP NetWeaver Developer Studio looks different compared with the Swing client. In the Swing client, a graphical mapping was supported, whereas the SAP NetWeaver Developer Studio-based mapping environment is script based using predefined macros that are called like functions in a programming language. The functions are identical to those you know from the Enterprise Services Builder. The mapping editor is separated in two halves. On the left you see the source message structure, and on the right, the structure of the target message (Figure 20).

Figure 20

The message mapping environment in SAP NetWeaver Developer Studio

You have two choices for mapping the fields:

1. Directly mapping fields on the Message Mapping Definition tab: Drag and drop fields from the left to the right. In this case, drag and drop the Firstname and Lastname fields from the left to the Fullname field on the right. The fields are connected via an orange line and a symbol indicating the invocation of a function () will be added. To find out more details about the function being invoked, double-click the symbol. As a result, the scripting editor opens.
2. Using the scripting editor to map fields: To directly use the predefined functions, you can open the scripting editor by double-clicking the target field on the right (Figure 20). It’s the field that should contain the result of the mapping. In this case, you can double-click the Fullname field to open the editor in a separate window. For your orientation, the window’s title contains the target field (Figure 21).

Figure 21

The scripting editor for mapping fields

The white space on the left is the scripting area. You can either type your function calls manually (and benefit from the Ctrl-Space-combination for code-completion — a standard functionality of every text-based editor in Eclipse), or you can add them by double-clicking their names taken from the list of available functions on the right. In Figure 21, for example, the concat function has been chosen, and details of this function’s parameters appear in the small help window beneath its name.

As result of the first choice, the concat function was automatically used to concatenate the two strings. For the second choice, you have to complete the following steps:

1. Double-click the concat function with the function’s name appearing in the scripting area as a result
2. Enter an opening parentheses: (
3. Assign the first parameter to the function. This parameter has to be the Firstname field of the source message. As you can see from Figure 21, the fields of the source message are listed beneath the Context node. Expand all subnodes until the Firstname field is visible. Double-click it to add it automatically as the first parameter to the function or drag and drop the field after the opened bracket.
4. Enter a comma (,) so that the second parameter can be added
5. Assign the second parameter to the function. This time double-click the Lastname field from the source message. It is again automatically attached.
6. Enter a comma (,) so that the third parameter can be added
7. The third parameter reflects the delimiter by which the concatenated strings are separated. In this case this should be a space, so manually enter a blank surrounded by quotation marks (“ ”) as the third parameter.
8. Enter a closing parenthesis: )

These steps complete the final definition of your mapping: Firstname and Lastname are concatenated and separated by a white space. Click OK to close the scripting editor and save your changes to the message mapping.

Now you are ready to define the operation mapping that wraps the message mapping. Right-click the Operation Mappings node in the Enterprise Service Browser and select the New Operation Mapping entry from the context menu. The Create Operation Mapping dialog opens, asking for an appropriate name. Enter CustomerOut_to_CustomerIn_OM and click Finish to proceed. The operation mapping editor opens in a separate window. The layout of the window is comparable to the message mapping editor. On the right, you find the Operation Definition area comprising two tables labeled with Source Operations and Target Operations (Figure 22).

Figure 22

Define the source and target operations for the operation mapping

Add the two services you have defined so far: the Customer_Out_Service as the source operation and the Customer_In_Service as the target operation. Click the respective Add… buttons to the right of the tables that cause a dialog to open. In this dialog, navigate to the respective operations and select them. Once the operations have been chosen, click the Definition tab at the bottom of the window to actually assign the mapping program to be called (Figure 23).

Figure 23

Define the operation mapping

Obviously, a connection already exists. However, the concrete program to be called remains open. Double-click the function symbol () that is on the connecting line between the source and target messages to open the Mapping Programs dialog. This dialog allows you to find message mappings, Java mappings, or XSLT mappings and add them to the operation mapping. Click the Add button to add a new mapping (Figure 24).

Figure 24

Add a message mapping

By default, a message mapping is used as Type. However, by clicking the Message Mapping entry a drop-down list becomes available from which you could also assign an XSLT or a Java mapping. In this example, stay with the Message Mapping type and continue with the assignment of the concrete message mapping you just created. Click the empty Name field located to the right of the Message Mapping string (also circled in Figure 24). Within that field a new icon containing three dots appears (). Click it to open another dialog listing all mapping programs that fit to the selected outbound and inbound services (Figure 25).

Figure 25

Select the mapping program

You have defined only one mapping program that fits to the chosen interfaces, so the associated message mapping is listed in the dialog. Select it and click OK to assign it to the operation mapping.

Interfaces and mappings are in place now, which completes the prerequisites to build integration scenarios within the new PI Designer perspective. Finally, activate all your changes by right-clicking your change list that was created at the beginning of the article and choose Activate from the context menu (Figure 26).

Figure 26

Activate the change list

You receive a message confirming the successful completion of the activation (Figure 27).

Figure 27

Successful activation of the change list

Dr. Volker Stiehl

Prof. Dr. Volker Stiehl studied computer science at the Friedrich-Alexander-University of Erlangen-Nuremberg. After 12 years as a developer and senior system architect at Siemens, he joined SAP in 2004. As chief product expert, Volker was responsible for the success of the products SAP Process Orchestration, SAP Process Integration, and SAP HANA Cloud Integration (now SAP HANA Cloud Platform, integration service). He left SAP in 2016 and accepted a position as professor at the Ingolstadt Technical University of Applied Sciences where he is currently teaching business information systems. In September 2011, Volker received his Ph.D. degree from the University of Technology Darmstadt. His thesis was on the systematic design and implementation of applications using BPMN. Volker is also the author of Process-Driven Applications with BPMN as well as the co-author of SAP HANA Cloud Integration and a regular speaker at various national and international conferences.

 

You may contact the author at editor@SAPpro.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.