After you have discovered what the ideal architecture for an enterprise-ready composite application should look like, I show you how to take the next step. I explain in detail how to implement such an architecture using SAP NetWeaver Composition Environment (SAP NetWeaver CE) 7.2. This includes SAP NetWeaver Business Process Management (SAP NetWeaver BPM), the main tool you use to implement the loosely coupled scenario. Besides the technical aspects and tooling, I also review Business Process Modeling Notation (BPMN), which plays an essential role during the development process.

As I go through the development steps, I refer back to my first article in this update, which describes the principles you are applying in more detail. I assume that you are familiar with SAP NetWeaver CE and how to use the toolset that is shipped with it (e.g., the process modeler, Composite Application Framework [CAF], and Web Dynpro).

It is not possible to describe each and every click to build such an application. However, with the explanations I provide, you should be able get an understanding of which steps are necessary to run such a scenario.

The Scenario: An Investment Approval Process

To describe the major development steps of a composite application I use a demo scenario with the process flow depicted in Figure 1. You can identify two cooperating processes reflected by two pools named Composite Application and Contract Implementation Layer. The Composite Application pool represents the main business process — in this example, an investment approval process.

Throughout the article, I use either the term composite application or business process to reflect this process as it describes the business part of my example. A requester enters his order data in the Enter Purchase Request activity. After the request is approved, a purchase order has to be created in the back-end system.

You shouldn’t call external systems directly from within your composite application (to promote clear separation between the business and the technical part). You need to start another technical-oriented process, which calls the back-end systems, maintains cross-reference tables as well as all kinds of data transformations. While the technical process is running, the business process waits for completion of the technical part. Once the data has been written to the back-end system, the technical process informs the business process about its finalization and wakes it up.

The key point to understand is that you model both processes using BPMN so you can use SAP NetWeaver BPM to execute the BPMN models. In essence, BPMN performs three fundamental roles:

• Common language between business and IT people, bridging the communication gap between business and IT
• Implementation language for business as well as technical processes

• Means to implement loosely-coupled SOA

Follow a Top-Down Approach

The business process is the driver of a composite application. Therefore, you model the process flow as depicted in Figure 1 first. You can achieve this by using the modeling capabilities of the process modeler which is part of SAP NetWeaver BPM. Keep in mind that you need two process models to implement the overall scenario. Although I depict both processes in one process model (Figure 1) this is only for explanation purposes. It makes it easier to describe the cooperation between the two. However, you have to create two distinct models in the SAP NetWeaver Developer Studio.

Figure 1

Loosely coupled composite scenario implemented using two cooperating processes

After modeling the two processes, you have to add UIs to human activities and service calls to automated activities to execute the models. With SAP NetWeaver CE 7.2, a new feature improves your productivity in creating UIs that have to interact with SAP NetWeaver BPM. You can now generate Web Dynpro or SAP NetWeaver Visual Composer UIs based on the data that makes up the process context.

The generated UIs automatically fulfill the contract between the process environment and the chosen UI technology. The UIs define events which, when fired, indicate the process environment that the user has finished his entries and they are automatically able to read and write data from and to the process context.

Without the new UI generation feature, you had to implement this contract manually. The process context itself represents the brain of your process: it is possible to store data in the process context which will exist during the lifetime of the process. Process steps can read and write data from and to the context and the process framework handles the transactional integrity.

To define the process context, you need an XSD file that describes the context’s data structure. Figure 2 shows what the code looks like for my example.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<schema xmlns="https://www.w3.org/2001/XMLSchema" xmlns:tns=
"https://www.example.org/approvalprocess" elementFormDefault="qualified" 
targetNamespace="https://www.example.org/approvalprocess">
 
    <element name="InvestmentApprovalProcess" type="tns:InvestmentApprovalProcess"/>
 
    <complexType name="InvestmentApprovalProcess">
          <sequence>
                   <element name="region" type="string"/>
                   <element name="productID" type="string"/>
                   <element name="quantity" type="decimal"/>
                   <element name="price" type="decimal"/>
                   <element name="totalAmount" type="decimal"/>
                   <element name="comment" type="string"/>
                   <element name="internalReservationID" type="string"/>
                   <element name="approved" type="boolean"/>
          </sequence>
    </complexType>
</schema>

The <element> entries in the middle comprise the actual data fields. I discuss most of them while walking through my scenario. After you have imported the XSD file or created it from scratch within the SAP NetWeaver Developer Studio, you can drag and drop the associated data object into your process model (Figure 3).

Figure 3

Process context available as data type within the Composite Explorer

Based on this structure, the system can generate the UI automatically during the creation of tasks for human activities. For example, in the first step of my process, I want to enter order data such as the product’s ID and price, the order quantity, the region from which the order originates, and a comment that describes a reason for the order. As these fields are also part of the process context, you can simply pick them while creating a task for the human activity. You can create a new task for a human activity by starting the New Task Wizard:

1. Right-click the human activity Enter Purchase Request and choose Properties from the context menu to open the Properties tab beneath your process model.
2. On the properties tab click the Task button in the button bar on the left side.
3. From the Task drop-down list choose New…. The New Task wizard opens.

In Figure 4 which shows the New Task wizard, select the Generate UI Component check box, and then click the Next button. In the next screen, select the fields for the UI and click the Finish button (Figure 5).

Figure 4

Activate UI generation in the New Task wizard

Figure 5

Select the fields for UI generation from the process context

In Figure 5, I selected a special field called internalReservationID. What is this field good for? We are only applying best practices: remember our recommendation discussed in the other article that data entered in an UI is never written back synchronously to backend systems. Instead we have to store the data locally and hand back an internal ID to the end user. It’s exactly this number that is stored in the internalReservationID field.

The question is how can you save the entered data in the database and who is responsible for generating the internal ID? The answer is pretty simple: use the CAF with its business entity modeling capabilities for this purpose. With its help, you can easily model an appropriate business entity, make its create-lifecycle method available as a Web service, and at the same time enable the create-method to generate a primary key for the stored data record. You can then use this primary key as the internal ID and call this Web service from the UI. Figure 6 displays the business entity within the CAF environment.

Figure 6

Business entity named InternalReservation for storing entered order data

Now that the business entity with its Web service is in place and a raw skeleton for the UI has been generated, the next question is how to integrate the call for storing the data within the UI? This can best be explained by using an SAP NetWeaver Visual Composer UI. Figure 7 depicts the design board of SAP NetWeaver Visual Composer for my scenario.

Figure 7

SAP NetWeaver Visual Composer design board for the Enter Purchase Request activity

Here I use an SAP NetWeaver Visual Composer standard UI component: the wizard component. In my example I have configured it to contain two UI steps: the Order Form step and the Order Confirmation step. The Order Form step in Figure 8 allows the end user to fill out the order form. When the user clicks the Create Order button, the system calls the create method of your business entity, as shown by the connecting arrow from the Order Form to the service method create in Figure 7.

Figure 8

Order Form step of the Enter Purchase Request activity

The primary key that CAF creates automatically is returned in the second wizard step called Order Confirmation (Figure 9). It contains only one field showing the generated ID. For the rest of this article, assume that an ID with the value 4711 was created.

Figure 9

Order confirmation step of the Enter Purchase Request activity

Because you are not calling any external systems, the response is fast. This is exactly what you are aiming for because the end user is waiting in front of the computer and you don’t want him to wait any longer than necessary. You have now finished the first half of the asynchronous write scenario. Next I’ll show you how to implement the actual writing to the back-end systems 

Implement the Writing to the Back End

If you take a look at the process model in Figure 1, the second human activity, Approve Purchase Request, executes next. As it has no influence on the asynchronous scenario, it is sufficient to say that it’s just another generated UI for the approver, which allows him to accept or reject the request. For this example, assume that the approver accepts the request.

As a result, you reach the automated activity Create Purchase Order, which is connected via a dashed arrow to the second process named Contract Implementation Layer. In my example, the dashed arrow reflects the asynchronous triggering of the technical process (right side) by the business process (left side).

An associated message-based event (Web service interface) triggers the technical process. Recall that a composite application has certain requirements with regards to external business functionalities, which it addresses in form of interfaces. The composite application contains (in the form of a contract) which data it provides and which functionality it expects from the service contract implementation layer. Ideally, you define the interface contract using WSDL and a canonical data type system. Figure 10 shows what this code might look like for my example. Don’t forget to either import it into your process project or create it there from scratch.

<xsd:element name="createPOOperation">
          <xsd:complexType>
                   <xsd:sequence>
<xsd:element name="internalReservationID" type="xsd:string"/>
                             <xsd:element name="productID" type="xsd:string"/>
                             <xsd:element name="quantity" type="xsd:decimal"/>
                   </xsd:sequence>
          </xsd:complexType>
</xsd:element>

The start event of the service contract implementation layer has to implement the contract. In addition to the ordered product (identified by its product ID) and quantity, the service contract implementation layer receives the internal ID 4711 created during the first activity of the example business process. By using interfaces and implementing them in additional BPMN processes, you gain the best separation between the composite application (with its interface requirements) and the respective implementations (which can be different depending on the landscape your composite should run against).

You may wonder why the implementation of an interface should be covered by BPMN processes. Wouldn’t it be enough to implement them by simple services using CAF, pure Java, or any other programming language? You are right. The decision about the technology used for implementing the functionality is up to you. However, for critical asynchronous write operations (and I’m only talking about this use case now), I recommend BPMN processes.

Why? As it turns out later, you typically must coordinate several service calls, especially if the data has to be updated in multiple back-end systems. Keep in mind that you have to watch out for any errors that might pop up during these service calls. In many cases, you can only solve these errors by involving experts — leading to processes with human interactions for which SAP NetWeaver BPM is best suited. For synchronous read operations I do not recommend BPMN processes. Take the fastest technology that fulfills your needs.

Model the Trigger in SAP NetWeaver BPM

Right-click the start event in your technical process, which represents the contract implementation layer, and select Properties from the context menu. On the Properties tab beneath the process model, click the Event Trigger entry on the left (Figure 11).

Figure 11

Define a trigger for the start event

For the Trigger Type choose Message. From the Trigger drop-down list, select New… to open the New Message Trigger wizard. The first wizard screen expects a trigger name such as CreatePurchaseOrderExternallyTrigger (Figure 12).

Figure 12

Provide a name for the new trigger

The Endpoint name field defines the Web service endpoint for your trigger. It is set by default. This allows you to kick off the technical process by invoking a Web service from the business process. Click the Next button to proceed. 

Figure 13 depicts the last wizard step of the New Message Trigger dialog. Select the appropriate service with the associated operation from the drop-down lists. The lists contain only those services for which their respective WSDL files have been imported. That’s why you had to import or create the interface shown in Figure 10. Click the Finish button to complete the connection between the Web service and the operation.

Figure 13

Select the interface for the operation that the technical process implements

Don’t forget that this is just an asynchronous call. The calling process does not wait for a response. It immediately proceeds to the Wait for Confirmation intermediate message event. It waits there for the finalization of the write operation in the technical process. The intermediate message event is a special BPMN construct. You can identify it by an envelope embedded within a double circle . It allows you to model asynchronous process communication.

I’ll show you what happens in the technical process (the process on the right in Figure 1). The first activity is the actual call to the back-end system. Now you are confronted with the proprietary interface of the external system. The technical process must handle all the data type conversions between the canonical data type system that the composite application uses (which was used for the contract as well) and the data type system that the back end uses. Although you lose independence from the back-end system, all data-type-related activities, protocols, and connection parameter handling are now centrally handled within the technical process. This makes maintenance easier. The composite application is freed from these kinds of activities and can therefore concentrate solely on the business problem.

Besides the technical aspects mentioned above, the technical process also handles errors close to the back-end system. On the border of the Create Purchase Order activity in the Contract Implementation Layer pool is the intermediate error event . It represents the start of the process execution path in case of an error during the service call. Instead of following the sequence flow to the next activity (Update XRef Table), the process continues with an expert who handles errors encountered in a given back-end system (Care For Error activity in the Contract Implementation Layer’s pool).

You can imagine the involvement of more than one expert if you must invoke several back-end systems. Each expert is responsible for one system. BPMN allows you to handle mixtures of automated and human activities in scenarios such as these.

Model Error Sequence Flows

How can you model error sequence flows with SAP NetWeaver BPM? Here you benefit from services that foresee error messages in their signature. In my example, I use the enterprise service PurchaseOrderCreateRequestConfirmation_In. All enterprise services delivered by SAP define a fault message. SAP NetWeaver BPM identifies those fault messages automatically and allows you to model the appropriate error sequence flows by using the following steps:

Step 1. Assign the enterprise service PurchaseOrderCreateRequestConfirmation_In  to the automated activity Create Purchase Order in the Contract Implementation Layer pool (you have to import the enterprise service beforehand).

Step 2. Right-click the Create Purchase Order activity and select Properties from the context menu.

Step 3. Click Boundary Events and then click the Add… button (Figure 14).

Figure 14

Define the boundary events

Step 4. The Select dialog pops up (Figure 15). It automatically recognizes the error message defined as part of the enterprise service’s signature. Select it and click the OK button. As result, the intermediate error event appears on the border of the activity.

Figure 15

Select the error message as a boundary event

Step 5. Move the mouse pointer over the newly created error event. The appropriate context buttons appear (Figure 16). Choose the one you need for the first step in the error sequence flow (e.g., a human activity) and drag and drop it into the Administrator lane. SAP NetWeaver BPM automatically creates the connection line between the error event and the activity for you. From there, add more steps as required. When you are finished with the error process flow, you can connect back to the original service call to retry the failed operation.

Figure 16

Model the sequence flow from the intermediate error event

Create a Cross-Reference Table in the XRef Table Activity

After writing the data successfully to the back-end system, you reach the Update XRef Table activity. In this step, you add an entry to a cross-reference table by associating the number the composite application (4711) created to the number the back end created.

You can implement this easily by using again a CAF business entity. Figure 17 depicts the CAF business entity representing the cross-reference table for our simple scenario. It consists of only two fields: the Composite’s internal ID and the externally generated ID of the back end. More fields would have been necessary for additional external systems. However, thanks to the automatically generated life cycle methods (create, read, update, delete, and find) in CAF, you can make the create and update methods available as Web services. You can then access these Web services from the BPMN model for consumption. In my simple scenario, the Update XRef Table activity calls the create method of the XRefTable business entity.

Figure 17

CAF business entity representing the cross-reference table

Composite Application Notification

The last step in the technical process is the notification of the waiting composite application. You do this in an asynchronous manner, which requires an appropriate interface. The steps necessary to implement this are identical to the activation of the technical process. For the Wait for Confirmation intermediate message event in the Composite Application pool you have to define a trigger. You do this exactly the same way as you did it for the start event of the technical process. Before you can model the trigger (e.g., with the name ConfirmExternalPurchaseOrderCreation-Trigger), you have to create the associated interface. Remember, all trigger definitions rely on interfaces. In my example, the interface might look like Figure 18.

<xsd:element name="confirmPOCreationOperation">
          <xsd:complexType>
                   <xsd:sequence>
<xsd:element name="internalReservationID" type="xsd:string"/>
                             <xsd:element name="comment" type="xsd:string"/>
                   </xsd:sequence>
          </xsd:complexType>
</xsd:element>

Don’t forget, this is the interface that the technical process calls to notify the waiting business process. Besides a comment about the outcome of the external order creation, you also return the composite’s internal ID. You may wonder if this is really necessary, but you need to figure out which of the waiting process instances has to be triggered – and this can only be done by a unique ID such as the composite’s internal ID. It is not that the waiting process instances require this information. It’s the process framework’s runtime environment that relies on this information for activating the right waiting instance.

How does this work in detail? Your order processes could potentially have been started several times by many people independently. The result is that several instances of our order process are running simultaneously. Over time the instances all wait at the intermediate message event. All of them are reachable under the same Web service address because you can only define one interface (trigger) for the intermediate message event and with that only one Web service address. How can you make sure that the right process awakes when the Web service is called by the technical process? As each instance has transferred its unique internal ID to the technical process, you can reuse this information as wake up criterion by handing it back from the technical process to the composite application.

The only thing that is still missing is the definition of a correlation condition, which describes which fields the runtime environment of the process framework has to compare to identify the correct process instance for notification. You define the correlation condition on the intermediate message event. Therefore, switch to the Properties tab of the intermediate message event and click Correlation Condition. The script editor opens (Figure 19).

Figure 19

Script editor for defining correlation condition

It allows you to formulate the appropriate condition. For defining the condition you have access to the fields of the process context (the Global node in Figure 19) as well as to the fields of the interface we associated to the event’s trigger (the Local node in Figure 19). In my example, the condition looks like Figure 20.

string-equal (DO_InvestmentApprovalProcess/internalReservationID,
              confirmPOCreationOperation/internalReservationID)

If the internal reservation ID of the process context is equal to the internal reservation ID handed over by the technical process, then the framework activates this exact instance. That’s all you have to do. The association of the correct process instance to be woken up by the Web service call has to be guaranteed by the runtime environment of the process framework (SAP NetWeaver BPM in my example).

Final Thoughts

Two final remarks:

• Note that the ID generated by the back-end system is not handed back to the composite application. Remember, the composite does not know against which systems it is running (this was one of our basic guidelines that I described in my other article). Therefore a number coming from any external system doesn’t make much sense for the composite application. The number represents back end-specific information and composite applications must not contain them.
• Keep in mind that you always have corresponding pairs of process instances. Each business process instance is associated with one technical process instance and vice versa.

After the process runtime evaluates the correlation condition and selects the correct instance, the process flow continues with the execution of the last human activity called Confirm Notification. It’s just a brief notification of the requester that his order request has been accepted and successfully created. After finalizing the human activity the process finishes properly.

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.