reading sample sappress 1317 sap hana cloud integration

8/17/2019 Reading Sample Sappress 1317 Sap Hana Cloud Integration

http://slidepdf.com/reader/full/reading-sample-sappress-1317-sap-hana-cloud-integration 1/36

Reading SampleSo far, you have learned about the development environment and

the runtime of SAP HANA Cloud Integration. In this sample chapter you will learn how SAP HCI supports advanced integration scena-

rios.

John Mutumba Bilay, Peter Gutsche, Volker StiehlSAP HANA Cloud Integration420 Pages, 2016, $69.95ISBN 978-1-4932-1317-7

www.sap-press.com/3979

First-hand knowledge.

“Advanced Integration Scenarios”

Contents

Index

The Authors

http://www.sap-press.com/3979




18

Chapter5

So far, we have introduced the development environment, as well as the

runtime, of SAP HANA Cloud Integration. The time has come to address

more sophisticated, real-life integration scenarios. Here, SAP HCI sup-

ports the integration developer wit h more advanced patte rns.

5 Advanced Integration Scenarios

In the previous chapter, we learned a lot about the inner working of SAP HANA

Cloud Integration (SAP HCI). You have seen how to work with SAP HCI’s data

model, how to enrich messages with data retrieved from an external OData ser-

vice, and how to solve mapping challenges using SAP HCI’s built-in mapping

engine. We will continue our journey in this chapter with topics to help you

address more advanced integration scenarios, such as:

Message routing

Working with lists

Asynchronous message handling

Let’s get started!

5.1 Message Routing

Cloud computing is currently one of the most talked-about topics in the IT indus

try. However, this trend of migrating toward cloud computing leads to an

increased heterogeneity of a company’s IT landscape, which itself brings increased

need for integration. Messages need to be exchanged between on-premise and

cloud applications. Fortunately, cloud-based integration solutions such as SAP HC

can help companies solve this integration challenge.

If we take a closer look at how messages are treated within SAP HCI, one question

comes up repeatedly: How can we model different message handling execution

paths (i.e., routes) in a single integration scenario? This question stands in the



Advanced Integration Scenarios5

182

middle of what is known as content-based routing, the topic of thi s section. Con-

tent-based routing (CBR) takes care of forwarding messages to the right recipient

depending on the contents of a message. As an example, let’s look at an order.

Depending on the type of item, an order might require different treatment within

the processing chain, or by dedicated backend systems. So, depending on the

message’s content, the order will need to be transferred to the respective system.

That’s what CBR is all about.

Content-based routing is nothing new. It is one of the famous enterprise integrationpatterns described in Hohpe and Woolf’s Enterprise Integration Patterns (2003,

Addison Wesley). As we know from previous chapters, Apache Camel is the basic

integration framework on which SAP HCI is built. One major goal of the Apache

Camel project was, from the beginning, the implementation of enterprise integration

patterns. Hence, we find the implementation of the content-based router in SAP HCI,

as well. Let’s see how you can apply the CBR pattern in your integration projects.

5.1.1 The Scenario

Let’s start with a look at the scenario we want to build. An example integration

flow using the content-based router is shown in Figure 5.1.

Figure 5.1 Example Integration Flow Using the Content Based Router

The depicted integration flow shows different message handling execution paths

after the diamond shape. The integration flow’s semantical behavior can be

described as follows: the sender on the left (represented by the Sender pool)

Message Routing

183

sends a message via SOAP channel to the integration flow. Again, we reuse the

same input message as Chapter 4. Its structure is shown in Figure 5.2.

Figure 5.2 Example Message

The incoming message starts the integration flow on the SAP HCI server. The

first Content Modifier step takes the order number from the message and

stores it in the message’s header area. Figure 5.3 shows the Content Modifier ’

configuration.

Figure 5.3 Writing Data into the Message's Header Area

The order number is stored in the newly-created header variable, OrderNo. We

can later access this value to define routing conditions. Next, the content-based

router comes into the picture (compare Figure 5.1). It is modeled using a BPMN

exclusive gateway (the diamond shape). As you know from Chapter 4, the entire

modeling environment of SAP HCI is based on BPMN (Business Process Mode

and Notation). In BPMN, the exclusive gateway is used to indicate the split of the

sequence flow in several independent execution paths. Exactly one of the path

leaving the gateway (which is also known as a gate in BPMN nomenclature) wil

later be executed at runtime, depending on some conditions, which are attachedas labels to each of the outgoing sequence flows. However, if you take a close

look at the gates, you will recognize one exception: the sequence flow leaving the

gateway vertically, which is decorated with the tick mark , has no condition




184

associated with it. This is a so-called default gate, and is executed during runtime

in case none of the other conditions meet the Boolean value TRUE. Now, we can

describe the behavior of the gateway as follows:

If the incoming order number equals 10249, the upper path will be followed.

If the incoming order number equals 10250, the gate in the middle will be

taken.

In all other cases, the default gate will be activated.

In order to verify the correct behavior of the gateway during runtime, we will set

the body of the message via the respective Content Modifier shapes, which are

connected with each of the three sequence flows leaving the gateway. The Con-

tent Modifier steps write the following messages as reply into the message’s

body:

orderNumber = 10249 for the upper sequence flow.

orderNumber = 10250 for the sequence flow in the middle.

orderNumber unknown for the default gate.

Figure 5.4 shows an example configuration for the uppermost Content Modi-

fier .

Figure 5.4 Configuration of the Content Modifier for the Uppermost Sequence Flow

5.1.2 Configuration of the Content-Based Router

Now we know how the content-based router should behave during runtime. But

how is this achieved during design time? Where can you find the gateway in themodeling palette of SAP HCI’s graphical editor? Take a look at Figure 5.5. In the

main menu of the palette, you will find the Message Routing shape .

Message Routing

185

Figure 5.5 Router Shape in the Palette of SAP HCI's Modeling Environment

Once you click on the Message Routing diamond, a sub-menu opens, revealing

at last the Router symbol (Figure 5.5). Click on it, move the mouse into the poo

for the integration flow, and click again to position the shape. Afterwards, mode

the three Content Modifiers, and connect them with sequence flows from the

diamond shape to the respective Content Modifier activities. Note that you can

only configure the gateway once you have connected it with the three previou

steps, otherwise you won’t be able to configure the gates correctly, since you

won’t have access to the sequence flow’s properties to define the labels and eval

uation conditions. So, let’s configure each gate, one after another. We will star

with the uppermost one. Click on the sequence flow, leaving the gateway so tha

its color turns to orange (Figure 5.6).

Figure 5.6 Selecting a Sequence Flow Leaving the Gateway for Configuration

As always, you will be able to configure the attributes of the selected shape in the

Properties section, found beneath the process model. In our case, we want to tel

the runtime engine that the execution of the model should be continued on theupper path of our model, in case the order number equals 10249. You have two

options for defining such a routing condition:




186

You directly access the contents of the message (which is actually in the body

area of Camel’s message model) and retrieve the value which should be used

for the decision from there.

You make use of header variables, which have been declared and set before.

Note

The first option is only poss ible for XML-based message content. If your incoming mes-

sage isn’t available in XML, you will have to convert it first.

Let’s begin with the first option. Here, you have to define an XPath expression to

the field you want to test. In our case, it is the orderNumber field of the incom-

ing message (Figure 5.2). Hence, the configuration looks like the one depicted in

Figure 5.7.

Figure 5.7 Defining the Condition for the Uppermost Sequence Flow

The Name field holds the string that shows up as label attached to the sequence

flow in Figure 5.1. The Expression Type dropdown list shown in Figure 5.7,

which contains the values XML and Non-XML, is of particular importance. The

selected value influences how the Condition field is interpreted by the execution

engine during runtime. If XML is chosen, the Condition will be interpreted as an

XPath expression. If Non-XML is chosen, it is interpreted as an expression using

the Simple Expression Language. We will see an example for the second casewhen we define the other gate. For now, though, stick with the XML case. The

Condition is formulated using a classic XPath expression. You can also combine

Message Routing

187

several expressions using the logical operators and, and or (e.g. //orderNumber =

'10249' or //orderNumber = '10250') to formulate more sophisticated routing

logic.

For the second gate, we will make use of the header variable OrderNo, which we

created by the invocation of the very first Content Modifier in Figure 5.1, in

conjunction with the configuration shown in Figure 5.3. The condition can be

formulated now, as indicated in Figure 5.8.

Figure 5.8 Configuring the Gate's Condition Using the Content of a Header Variable

We can easily identify the typical Camel Simple Expression Language for access

ing variables ($ or {}, for example). The string header in ${header.OrderNO} indi

cates the area from which we want to load the value (the message’s header area)

and the OrderNo after the dot indicates the name under which we stored the value

previously. Note that the Expression Type dropdown list has been changed to

Non-XML. Because you use this dropdown list to define how the Condition

string is interpreted, it should be clear that you cannot mix XML-based variables

with Camel-based variables. If you try to mix them, e.g. ${header.OrderNo} =

'10250' or //orderNumber = '10251' you will receive a validation error (see

Figure 5.9).

Figure 5.9 Validation Error if the Expression Contains a Mixed Expression of XML andNon-XML Parts




188

The definition of the last gate is probably the easiest part of the content-based

router’s configuration. We simply have to set the Default Route checkbox (see

Figure 5.10) in order to define the gate, which should be followed during runtime

if none of the explicit conditions of the other gates evaluate to TRUE.

Figure 5.10 Defining the Default Route

From what you have learned so far, you know how to formulate expressions for

the XML setting of the Expression Type field shown in Figure 5.8. You now need

to apply the rules laid out in the XPath specification defined by the W3C (World

Wide Web Consortium). But what do you have to consider for the non-XML

expressions? Which operators are allowed here? For your convenience, the table

from the SAP HANA Cloud Integration help website has been copied (the original

can be found at https://cloudintegration.hana.ondemand.com/PI/help) for you,which summarizes the operators allowed for formulating non-XML expressions.

The table has been reproduced in Figure 5.11, including some examples.

Figure 5.11 Usage of Operators in Non-XML Expressions

Message Routing

189

5.1.3 Running the Content-Based Router Scenario

Now that our configurations are complete, we can finally run the scenario. Use

SOAP tool of your choice (e.g., SoapUI) and invoke the solution. We’ll use the

input message depicted in Figure 5.2. Depending on the order number’s value

you will receive respective replies from the integration flow. In case your order

number is 10250, the reply should look similar to Figure 5.12.

Figure 5.12 Reply Message in Case Order Number of Input Message Was Set to 10250

If you provide a number for which no routing rule exists, you will see the respons

shown in Figure 5.13, because the default route of the gateway was fired.

Figure 5.13 Reply Message in Case an Order Number Was Provided for Which No RoutingRule Exists

At this point, we could stop with the description of the content-based router

However, one interesting question has not yet been answered: what happens i

the routing rules contain overlapping conditions? Mistakes are always possible

and especially for complex routing conditions these mistakes may sometimes

result in overlapping conditions, so that potentially two or more of the condition

could evaluate to true during runtime. Hence, more gates may be triggered. On

the other hand, we know that the exclusive gateway will trigger one, and only one

gate. So the question is: in the case of overlapping conditions, which of the gate

will be triggered, and can we influence the sequence in which the expressions wil

be evaluated? Let us try a little experiment. We will change the conditions in such

a way so that they overlap. Let’s change the condition of the gate labeled with

orderNumber = '10250'

to${header.OrderNo}

=

'10249'

. This overlaps with thegate already labeled with orderNumber = '10249' and its condition //orderNum

ber = '10249'. Both are checking against order number 10249.




190

Now, save your changes, deploy them, and run the scenario again using 10249 as

input value for the order number. Once we run the scenario in our own environ-

ment, we see the result shown in Figure 5.12. Thus, the changed path was exe-

cuted, although if you compare our design of the scenario shown in Figure 5.1,

you will see it is positioned in the middle of the three gates. One might think the

conditions are evaluated from top to bottom in the visual diagram, and so the

model’s visual appearance has nothing to do with execution sequence. Our exper-

iment proves that this is not the case. We also stress that our scenario works this

way. It may be that your scenario is still working correctly!

What else influences the execution sequence, then? The answer is hidden behind

the gateway shape itself. Select the diamond shape of the router and take a look at its

properties. In our example, the gateway has the properties shown in Figure 5.14.

Figure 5.14 Configuration of the Exclusive Gateway

Take note of the Order column: it tells us the sequence in which the conditions will

be evaluated. The route labeled with orderNumber = '10250' will be evaluated

first. Additionally, as the condition is true, we get the expected result. The second

row will no longer be evaluated, as the gateway has already found a valid gate, and

no more gates are allowed to fire because of the exclusive behavior of the gateway.

This explains the gateway’s behavior. But how can we influence the evaluation’s

sequence? The answer is rather straightforward: The order of the rows is deter-

mined by the connection’s modeling sequence. Every connection you are model-

ing from the gateway to any task following the gateway adds a new row to this

table. Note that every new row will be added at the bottom of the table. You can

conclude from this description how we created the process model shown in

Figure 5.1. We first drew the connection to the Content Modifier in the middle

Message Routing

19

(resulting in the first row in the table), then to the one at the top (second row in

the table), and finally to the Content Modifier at the bottom (third row in the

table). If we want to change the execution sequence, what do we need to do? Take

a look at Figure 5.14 again. We want the second row to be at the first position. So

in your process model, delete the connection responsible for the first table row

the connection labeled with orderNumber = '10250'. The second row moves up

to first place automatically, exactly like we want. Next, draw the connection tha

we just deleted again, add the label and the condition in its properties, and verify

the condition’s list at the gateway. It should now look like Figure 5.15.

Figure 5.15 Evaluation Sequence after Deleting and Redrawing of the Connection with the RouteName orderNumber = '10250'

Note the changed order sequence in comparison to the one of Figure 5.14. If you

invoke the route again with order number 10249, you will see the expected (cor

rect) result, as shown in Figure 5.16.

Figure 5.16 Returned Message after Correcting the Evaluation Sequence at the Gateway

To summarize, routing messages to different message handling paths is an

important aspect in every integration project. SAP HANA Cloud Integration is

based on Apache Camel, which implements typical enterprise integration patterns. One of those patterns is the content-based router (CBR), whose task it is to

split the sequence flow into different independent execution paths, which can

then be activated based on certain conditions. Exactly one of those execution




192

paths will be selected during runtime. You have learned how to model the con-

tent-based router in SAP HCI’s graphical modeling environment and how to con-

figure the conditions correctly. To define the expressions, you have two options

at your disposal: XML and non-XML. You learned when to use which option, and

how the condition’s evaluation sequence can be influenced. Now it is your turn

to work with the content-based router in your own integration projects.

5.2 Working with Lists

So far, you have learned quite a bit about SAP HANA Cloud Integration’s func-

tionality, the basic concepts behind it, and the various modeling techniques for

solving typical integration problems, such as message enrichment, message map-

ping, and message routing. However, in the examples so far, we focused on han-

dling messages containing just one item, such as a single order. In this section, we

will dive into the details of coping with messages comprising a list of entries.

Questions such as the following will be answered in the next sections:

How do I split up such a message into individual pieces?

How do I iterate over each list item?

How do I handle the resulting single messages in an SAP HCI message process-

ing chain?

How do I combine the results of each single message handling sequence back

into one response message?

5.2.1 The Scenario

In real-life scenarios, integrators are quite frequently confronted with input mes-

sages consisting of several items of the same message structure, grouped in a list

(e.g., order line items). The integrator wants to iterate over the list: individual list

items have to be separated and individually managed by the integration flow.

Finally, the result of each individual message handling procedure needs to be

consolidated into one response message, sent to either the sender o f the message

(in the case of a synchronous scenario) or to the final recipient (in the case of anasynchronous scenario). In order to illustrate this functionality using SAP HANA

Cloud Integration, we will use the input message shown in Figure 5.17 through-

out this section.

Working with List

193

Figure 5.17 Example Message Comprising a List of Order Numbers

Figure 5.17 is based on a WSDL file which was created using the Enterprise Services Builder of SAP Process Integration. You can, of course, use any XML-tool

supporting the WSDL-standard. We have included our WSDL file, with the book

downloads at www.sap-press.com/3979. The name of the file is SendOrderList_

Async.wsdl. The message contains a list of order numbers; the other fields are no

yet relevant. Our goal is to split the message into individual order messages

enrich each individual order with order details (for example shipping date, ship

ping city, shipping address, etc.), and send back the enriched message as a reply

to the sender in a synchronous scenario. We will solve this problem in two steps

The first step is to understand splitting one input message into several individua

messages (splitter pattern), and then joining back the pieces into one large mes-

sage (gather/merge pattern). The second step explains how to enrich the individ

ual messages with order details (enricher pattern) and then collect those results

into one large message. You can see by this example how patterns help to buildmore complex integration solutions. We want to encourage readers to recognize

(and to implement) solutions based on patterns. Once you understand the basic

principle, you can apply this knowledge to even more complex scenarios.




194

The key to splitting large messages into individual pieces, iterating over them,

and joining them back again into one large message, is the usage of two new steps

from SAP HCI’s web-based graphical modeler and positioning them correctly in

your message processing chain (aka route). The Splitter and Gather steps are

used in the integration process model depicted in Figure 5.18. The figure shows

the message processing chain for the first step of the implementation plan, as out-

lined above.

Figure 5.18 Splitting a Large Message into Single Pieces and Collecting them Back Using Gather

You can find the Splitter step at the beginning and the Gather step at the end of

the processing chain. It is important for the overall understanding of the entire

splitter-gather construct to recognize the following:

1. The steps in-between aSplitter and a Gather step (the two Content Modifier

steps in our case) are executed as many times as the Splitter creates individual

messages.

2. Each step within a Splitter /Gather pair will receive the separated individual

messages, which the Splitter has created, as an input message, one after

another.

3. It is possible to model a splitter scenario without a Gather step. In those cases,

all steps following the Splitter will be executed repeatedly until an end event

is reached. So, the repeated execution of steps is dependent on the Splitter

step, not on the Gather step.

5.2.2 Configuring the Integration FlowLet’s see what the configuration looks like for our scenario. As a reminder, we

will repeat the settings of the Sender pool and the message flow from the Sender

pool to the Start message event. The sender is configured as in Figure 5.19.

Steps between Splitter and Gather

will be repeated for every list item

Working with List

195

Figure 5.19 Configuration of the Sender Pool

Notice the entry of the Authentication

Type

dropdown field. We’ve set it toBasic Authentication to allow the sender to provide username and password

credentials while invoking the integration flow.

Figure 5.20 shows the SOAP adapter’s configuration. You can set the values by

selecting the message flow in the process model (the color of the dashed arrow

from the Sender pool to the Start event changes to orange when selected).

Figure 5.20 SOAP-Channel Configuration

The Address field on the Adapter Specific configuration tab is important, here

The address entered will later be part of the URL used to call the flow.

Let’s continue with the integration flow itself. The first step in the flow, after

instantiating it, is the Splitter activity. As this step is new, we will explain it in

more detail. The first question we have to answer is, where can you find the activ

ity during development? You can find it in the palette on the left of the modeling

environment following the path Message Routing Splitter ( , Figure 5.21)

General Splitter (Figure 5.22).




196

Figure 5.21 Opening the Splitter Sub-Menu from the Palette

Figure 5.22 Selecting the General Splitter from the Splitter Sub-Menu

SAP HCI supports several different splitter types. In this section, we will focus

solely on the General Splitter . For more information about the other splitter

alternatives, see the upcoming note.

Splitter Implementations

SAP HANA Cloud Integration provides several splitter implementations (see Figure

5.22). In this chapter, we used the General Splitter, which will be described in more

detail throughout this chapter. In this note box, we will briefly discuss the other splitter

implementations.

The splitter that behaves most like the General Splitter is the Iterating Splitter. It also

splits up a composite message into a series of individual messages, but it doesn’t copy

the so-called enveloping parts of a message to the single split messages. But what are

enveloping elements, exactly? They are the message parts of the original incoming mes-

sage above the nodes which are used for splitting. The documentation for SAP HANACloud integration (found at https://cloudintegration.hana.ondemand.com/PI/help), con-

tains a visual depiction of the differences between the General Splitter and the Iterat-

ing Splitter (Figure 5.23).

Working with List

197

Figure 5.23 Difference between General Splitter and Iterating Splitter (Taken from SAP OnlineHelp for SAP HCI)

The Iterating Splitter simply copies the parts beginning with the splitting tag (C, in the

example shown in Figure 5.23) and the sub-nodes, whereas the General Splitter also

copies the nodes above the splitting tag (A and B in the example above). This is espe-

cially important if you want to navigate to elements in the tree structure using absolute

XPath expressions.

One dedicated splitter takes care of IDoc messages. It is the IDoc Splitter which is used

for composite IDoc messages. It splits the composite IDoc into a series of individual

IDoc messages, including the enveloping elements of the composite IDoc message.

There are no special configuration settings for this splitter available.

Finally, SAP HANA Cloud Integration supports the PKCS#7/CMS Splitter. PKCS stands

for Public-Key Cryptography Standard, which is used to sign and encryp t messages. It is

useful if a client sends a message that is PKCS#7-signed, and contains both a signature

and content. This splitter type breaks down the signature and the content into separate

files. For configuration, you can provide names for the files that should contain either

the payload or the signature after the splitting step. You can also prescribe which file

should be handled first after splitting (the signature or the content file), and you candecide whether the payload/signature should be BASE64 encoded after splitting.

A

B

C

C

C

C

A

B

CA

B

CA

B

CA

B

C

C

C

C

C

GeneralSplitter

Xpath=//C

IterativeSplitter

Xpath=//C




198

After positioning the General Splitter shape in the main pool named Integra-

tion Process (Figure 5.18), you can set its properties. We’ve configured it with

the parameters shown in Figure 5.24.

Figure 5.24 Configuration of the Splitter Step

Let’s walk through the parameters one by one:

1. XPath Expression

This directs the integration engine during runtime to search for the given tag in

the input message and take it as the split argument. In our example, we’ve used

the relative path //orders. Relative paths are indicated by the double-slash at

the beginning, and are quite convenient for allowing the engine to search forthe tag’s occurrence in your input message. The alternative would have been to

use absolute paths starting with a single forward slash. As a consequence, you

would need to know the exact path, from the root to the tag, that should be

used for splitting. If you wanted to extend the message later, for example by

adding tags between the root tag and the splitting tag, the absolute path would

no longer be valid, as it doesn’t consider the new tag on the way from the root

to the splitting tag. Hence, absolute paths are quite static and error-prone when

it comes to changes on the message’s structure. Conversely, this error would

not happen with a relative path.

Let’s see how the definition of the XPath expression influences execution

during runtime. Take a look at our example input message in Figure 5.17. We

have three <orders> tags in our message. As such, the splitter will generate

three individual messages. Each individual message forwarded to the two Con-tent Modifier steps following the Splitter looks like Listing 5.1 (with differ-

ent order number values):

Working with List

199

<orders>

<orderNumber>10248</orderNumber>

<customerName>?</customerName>

<orderAmount>?</orderAmount>

<currency>?</currency>

<taxAmount>?</taxAmount>

</orders>

Listing 5.1 Individual Message Containing Exactly One Order

Hence, the single messages will also contain the <orders> tags. Consider thiwhile processing each of the individual messages. If you want to understand

what the message produced by the splitter looks like in greater detail, read on

to Section 5.2.3.

2. Grouping

With the grouping parameter, you define the number of items that should be

grouped together into one message for individual processing. As we have cho

sen 1 as the value, every occurrence of <orders> results in a dedicated individ

ual message for further processing. If we had selected 2 as our value, the splitte

would group the first two items as a single message, the next two items in the

second message, and so on. So, assume an input message contains 10 items in

total. How many messages would the Splitter generate if the Grouping param

eter was set to 2? It would produce 5 messages, each containing 2 items.

3. Timeout

You have the option to provide a time limit for processing your complete mes

sage using the Splitter . If this time limit is violated, the processing chain wil

be aborted, resulting in an error.

4. Streaming

The Streaming parameter is important with regards to memory consumption

Normally, the splitter works on messages by loading them completely into the

main memory. However, messages can get quite large. Think about payment

which are being sent to a bank once a day. They are collected over the course

of the day, and forwarded sometimes at night. These collected messages can

become huge and it doesn’t make sense to load them entirely into main mem

ory before processing them (and it is sometimes impossible to do so). There-

fore, it is useful to let the Splitter start working on the incoming streamed




200

data, even though it is not yet entirely loaded. This is called streaming , as it

allows you to read chunks of data, work on it, read another chunk, and so forth,

until the entire message is processed.

5. Parallel Processing

As the name indicates, this parameter allows you to run the individual message

processing tasks in parallel, leveraging Java’s concurrency features using thread

pools. By parallelizing tasks, you can get more work done in less time. How-

ever, the execution sequence cannot be guaranteed, as the threads run inde-

pendent of each other.

6. Stop On Exception

If this checkbox is set, the route’s processing will immediately stop in case of an

error, and that error will be propagated back instantly. Otherwise, the splitter

continues working on the individual messages and reports the error back at the

end, after handling the complete input message.

Now that we have an understanding on how the Splitter handles the incoming

message, we can continue with the first Content Modifier . Its behavior has been

described several times already. As such, it is enough to just take a quick look at

its configuration in Figure 5.25.

Figure 5.25 Configuration of First Content Modifier in the Route

Note

As this Content Modifier is placed after the Splitter step, it is invoked for each individ-

ual message created by the Splitter representing one order out of the original message’s

order list. This is crucial to understanding the entire route.

Working with List

20

We are setting a variable named OrderNo in the message’s header area and storing

the current order number of the current item for later reference. We also could

have taken //orderNumber as an entry for the Value field as it is a relative path

and there is only one order number available in each individual message.

The recently stored header value will be retrieved by the second Content Modi

fier and copied into the result message as the configuration in Figure 5.26 shows

Figure 5.26 Configuration of Second Content Modifier in the Route

Again the second Content Modifier will also be invoked for each individua

message. It is the Gather step which finally collects all the individual single mes

sages created for each invocation of the Splitter into one bulk message. Figure

5.27 shows the Gather step’s configuration.

Figure 5.27 Configuration of the Gather Step

All of the resulting single messages are of the same format (hence, the Incoming

Format drop-down field is set to XML (Same Format)), and the Gather step

should simply put each of the individual pieces together into one result message

Consequently, the Aggregation Algorithm’s drop-down field is set to Combine

Which other configuration options does the Gather step provide? It actually

depends all on the entry chosen from the Incoming Format dropdown list. The

list provides three options:




202

Plain Text: For the Aggregation Algorithm, only Concatenate is allowed.

All of the plain text messages generated by the single messages will simply be

concatenated to one large string, one after another. This is the result being

propagated back to the caller.

XML (Different Format): For the Aggregation Algorithm, only Combine is

allowed, which is similar to the behavior of the Concatenate option in the pre-

vious case. The individual XML fragments from the single messages will be

brought together in one response message using a multi-mapping from SAP

Process Integration’s mapping engine.

XML (Same Format): If you choose this option, you can influence the construc-

tion of the response message in two ways:

Firstly, you can also apply the Combine option of the Different Format

case. Its behavior is identical to the one just described.

Secondly, there is one more option that allows you to copy parts from the

source message into a user-defined envelope consisting of XML tags. The

XML node from which parts of the source message should be copied is for-

mulated using an XPath expression. The XML envelope is defined using an

absolute path definition, such as /root or /level_1/level_2. The associated

configuration screen is depicted in Figure 5.28. The behavior is actually

pretty simple: the XPath expression of the field with the label Combine from

Source (XPath) takes the source message (the single message created by the

Splitter ), navigates within that message to the node specified by the XPath

expression, and copies the node, including all nested XML-sub-nodes. It

takes the copied XML-sub-tree snippet and pastes it after the tags that the

user has defined as the envelope. The idea behind the envelope is that every

valid XML document requires one root element. And this is exactly what you

can define in the Combine at Target (Path) field: the root element (e.g.,

/root) or, if necessary, an absolute root path (e.g., /level_1/level_2 ).

During runtime, the copied XML sub-tree will be pasted after the node(s)

given in the Combine at Target (Path) field. In other words, the node in

the Combine at Target (Path) field is the parent of the snippet that needs

to be inserted. The corresponding closing tag(s) of the envelope will auto-

matically be added, once the gathering has completed (e.g., </root> or</level_2></level_1> ).

Working with List

203

Figure 5.28 Configuration of Gather Step in Case the Single Messages Should be Combined UsingXPath Expressions

Let’s take a look at a concrete example. We’ll assume the Splitter generate

two messages, as shown in Listing 5.2 and Listing 5.3 (they will later be the

source messages in the Gather step’s configuration):

<payload>

<route>

<multicast>Parallel</multicast>

<branch>A</branch>

</route>

</payload>

Listing 5.2 First Generated Splitter Message

<payload>

<route>

<multicast>Parallel</multicast><branch>B</branch>

</route>

</payload>

Listing 5.3 Second Generated Splitter Message

Next, assume the following settings for the configuration of the Gather step

Combine from Source (XPath) (only absolute XPath expressions are

allowed for this field): /payload/route

Combine at Target (Path): /xyz/abc

The final resulting message looks like Listing 5.4:

<xyz>

<abc>

<route>


<branch>A</branch>

</route>




204

<route>


<branch>B</branch>

</route>

</abc>

</xyz>

Listing 5.4 Combined Message Generated by Gather Step

You can now easily understand how this result message was created: the engine

copied the parts from the source messages starting at the /payload/route node,including the <route> tag and all nested nodes, and pasted it into the target mes-

sage, which starts with the <xyz><abc> nodes representing the opening part of the

envelope. Remember: the pasting will be done for all messages resulting from the

splitter. Hence, we have two <route> tags in between the envelope. Finally, we

add the closing tags of the envelope. They can be derived from the definition of

the Combine at Target (Path) field. As the definition for that field was /xyz/abc,

the closing tags must be in opposite sequence, resulting in </abc></xyz>.

Note

It is not mandatory to provide an entry for the Combine at Target (Path) field. If you

leave the field empty, the resulting message will have the same tags that are specified in

the Combine from Source (XPath) field. Referring to the example above, the resulting

message would start with <payload><route>.

5.2.3 Running the Integration Flow

Now that we have configured the scenario completely, we can finally run it. Save

your changes and deploy your integration flow. Don’t forget to retrieve the URL

for invoking the integration scenario from SAP HCI’s Monitor (refer back to

Chapter 4, Section 4.1 for instructions on how to retrieve the URL). Provide the

URL in the SOAP-tool of your choice (e.g., SoapUI) and invoke the integration

flow. The result should look like the one in Figure 5.29.

The flow successfully retrieved the order numbers from the incoming message

containing the order list and created an appropriate response message, which is

the exact result we hoped to achieve.

Working with List

205

Figure 5.29 Final Response Message after Invoking the Integration Flow with a List of OrderNumbers

What Is the Splitter Delivering to the Processing Chain?

In some situations, it might be useful to fully understand what the individual

messages produced by the Splitter actually look like, and which ones reach the

next step of the integration flow. Maybe you want to pick a concrete field by an

absolute XPath expression instead of using a relative XPath due to a potentia

name conflict. In this case, you need to know exactly what the single message

looks like, otherwise your absolute path won’t work. Let us show you how to

achieve this. We’ll take the process model of Figure 5.18 as the basis for this task

Next, configure the first Content Modifier , as is shown in Figure 5.30:

Figure 5.30 Adding the Complete Single Message into the Header Area

We are using an absolute XPath expression pointing to the root of the received

single message. Hence, we really put the complete message into the header vari

able named splitterResult. In the second Content Modifier , we now simplypick the variable’s content and place it into the body. The result of the second

Content Modifier ’s configuration is shown in Figure 5.31.




206

Figure 5.31 Copying the Splitter's Message into the Body

Running the scenario results in the output depicted in Figure 5.32:

Figure 5.32 Result Message after Invoking the Integration Flow

Working with List

207

In between the <splitter_single_message> tags, you can now easily identify the

fragment that was produced by the splitter. With this knowledge, you can now

formulate the absolute path within that single message to the orderNumber field

The path is as follows: /demo:OrderList_MT/orders/orderNumber . Let’s quickly ver

ify this by adjusting the two Content Modifier ’s configurations. You can find the

updated properties in Figure 5.33 and Figure 5.34.

Figure 5.33 Accessing the orderNumber Field via an Absolute XPath Expression in the First Con-tent Modifier

Figure 5.34 Pasting the Copied Order Numbers into the Result Message's Body in the SecondContent Modifier

Can we run this scenario now? Not yet: we have to consider one small, but

important, detail. Take a look at the Value column in Figure 5.33. How does the

XPath expression begin? It starts with /demo:OrderList_MT , right? The importan

detail is the namespace demo:. The message handling route is not aware of this

namespace and what it means. Hence, we have to explicitly declare the name

space in the route’s configuration. You can define some global settings for an inte

gration flow by clicking somewhere outside of the pools to reach the route’

properties beneath the process model. Once you can see the properties of the

integration flow, select the Runtime Configuration tab (see Figure 5.35).




208

Figure 5.35 Global Configuration Options for an Integration Flow

The Runtime Configuration tab allows you to define the namespace mappings

in a dedicated field. We’ve just copied the namespace definition from Figure

5.32. Remember to remove the quotation marks after pasting the string into the

Namespace Mapping field! Now the route is aware of the namespace and can

handle the XML fragment accordingly. Try the changed integration flow out. The

result should look like Figure 5.36, below.

Figure 5.36 Result Message after Picking the Order Number via Absolute XPath Expression

5.2.4 Enriching Individual Messages with Additional Data

We began with a relatively simple example in order to concentrate on the Split-

ter and Gather ’s behavior. However, we can now extend this example to some-

thing more useful by invoking an external OData data source and enriching ourresult message. This reflects a typical example where some basic data needs to be

enriched by external sources. In our case, we want to retrieve order details for

Working with List

209

each of the order numbers that we have extracted. In Chapter 4, Section 4.2, we

configured an OData connection to retrieve detailed data for order numbers. Thi

is exactly what we will do next: we will replace the second Content Modifier

(which actually just sets the body of the single message artificially with the

extracted order number) with a Request-Reply step invoking the OData service

and providing useful data as response for each single message the Splitter cre

ated. After adding the Request-Reply step into the integration flow, the scenario

finally looks like the one seen in Figure 5.37.

Figure 5.37 Integration Flow with Splitter, Gather, and the Invocation of an E xternal ODataSource

The configuration of the Request-Reply step is identical to the one described in

Chapter 4, Section 4.2, and can be found there.

Note:

The call of the Request-Reply step is executed for every order number of the original

incoming message. We can’t stress enough the importance of this specific behavior of

an integration flow making use of the Splitter step. All activities following the Splitter

are invoked for each single message generated by the Splitter until either the end of the

flow or the Gather step is reached! The invocation of the integration flow finally resultsin the response message shown in Figure 5.38.




210

Figure 5.38 Result Message Including Order Details Retrieved from the External OData Source

To summarize, the handling of messages containing lists of items are frequent sit-

uations integration solutions such as SAP HANA Cloud Integration have to deal

with. In this chapter, the Splitter step was used to split a message comprising

several order numbers into individual single messages, each containing one order

number. The individual messages can be treated separately by SAP HCI. After-

wards, SAP HCI can combine the results of each individual message processing

chain back into one integrated response message using the Gather activity. You

have learned how to configure both the Splitter and the Gather steps correctly

to benefit from the above-described message handling behavior. In the next sec-

tion, we will take a close look at asynchronous message handling scenarios.

Asynchronous Message Handling

21

5.3 Asynchronous Message Handling

The core task of an integration solution is the routing of messages across a com-

pany’s distributed IT-landscape, including connectivity to partners and suppliers

Such integration scenarios can be synchronous or asynchronous in nature. Syn

chronous means, in this regard, the following procedure:

1. A sender opens a connection to SAP HCI and sends a request message.

2. After sending the request message to SAP HCI, the sender does not close th

connection, because a reply is expected.

3. SAP HCI finds the receiver for the respective request message (for example, by

inspecting the message’s content), opens a connection to the receiver, and

routes the message to the receiver.

4. After sending the message to the receiver, SAP HCI does not close the connec

tion, either.

5. The receiver acts on the request message by creating a response message an

returns it to SAP HCI via the still opened connection.

6. After receiving the message, SAP HCI will close the connection to the receive

and route the received message as a reply message to the original sender.

7. The sender can now close the connection to SAP HCI after receiving the fina

reply message.

The connections from the sender to SAP HCI, as well as the connection from SAP

HCI to the receiver, are still open, as long as message processing is ongoing. The

communication involves a bi-directional message transfer in one session. Thi

message handling procedure significantly differs from asynchronous message

handling where the procedure looks like the following:

1. A sender opens a connection to SAP HCI and sends a message.

2. After SAP HCI receives the message correctly, it acknowledges its reception to

the sender.

3. After receiving the acknowledgement from SAP HCI, the sender closes the con

nection.

4. SAP HCI opens a connection to the receiver of the message and forwards iaccordingly.




212

5. After receiving the message completely, the receiver also acknowledges the

message’s reception to SAP HCI.

6. After receiving the acknowledgement from the receiver, SAP HCI closes the

connection.

The connections are immediately closed as soon as the messages have been con-

firmed by the receiving parties. The overall communication only involves a mes-

sage transfer in one direction. These are, in short, the main differences between

synchronous and asynchronous communication. But how does this knowledgeaffect our discussion of SAP HANA Cloud Integration? First of all, SAP HCI abso-

lutely must support both communication styles, as it is a general-purpose integra-

tion infrastructure that is prepared for all kinds of integration requirements.

However, in the previous sections, all communications were synchronous. This

has thus far been useful, because we were able to see the immediate results of our

integration flow invocations in the SOAP clients that we used to call the message

handling chains. Now the time has come to take a closer look at asynchronous

message handling as well, and how to influence the communication style.

5.3.1 Synchronous vs. Asynchronous Communication from SAP HCI’s

Perspective

Let us repeat some main aspects regarding the synchronous vs. asynchronous dis-cussion from Chapter 4, Section 4.1. One of the key terms used in that chapter

was exchange (Figure 5.39).

Figure 5.39 Structure of an Exchange

Exchange

In-Message

Headers

Attachments

Body

Out-Message

Headers

Attachments

Body

Exchange ID

Exception

MEP

Properties


213

An exchange is a term from Apache Camel terminology, and represents a con

tainer for a message while it is being processed inside the integration engine. We

know so far that the exchange will be filled with an In message only if it is an

asynchronous scenario, whereas the Out message within the exchange only plays

a role for synchronous scenarios, as discussed in Chapter 4, Section 4.1. Addition

ally, the communication type (synchronous or asynchronous) is determined by

the Message Exchange Pattern field (MEP) within the exchange. The MEP field

can contain two potential values:

InOnly: The route handles a one-way message and the sender doesn’t expect

reply from the respective receiver. Hence, the exchange carries an In message

only. InOnly represents the asynchronous use case.

InOut: The route handles a request-response message. The sender expects a

reply from the route which will be stored as Out message in the exchange

InOut stands for the synchronous communication style.

Which component determines whether a message should be handled synchro-

nously or asynchronously? It is, in fact, the channel! This answer might surprise

you, but we will show you how to influence synchronous and asynchronous mes

sage handling in SAP HANA Cloud Integration by using the SOAP adapter.

We’re reusing the scenario we built in Section 5.2.1. For your convenience, we’ve

added screenshots of the scenario in Figure 5.40 and the associated input messagein Figure 5.41.

Figure 5.40 Demo Scenario for Splitting and Joining Messages

Ad d I t ti S i5 A h M H dli




214

Figure 5.41 Example Input Message for Demo Scenario

The integration flow, in essence, splits the incoming message into three individ-

ual messages. Each of these three single messages contains exactly one order. Thetwo Content Modifier steps are executed three times (for each of the single mes-

sages). The first Content Modifier extracts the order number from the single

message and writes it into the message’s header area, whereas the second Con-

tent Modifier retrieves the order number from the header area again and writes

the number, embedded inside orderDetails tags, into the body area of the mes-

sage. As this is done three times, the resulting message contains just the three

order numbers, each one surrounded by orderDetails tags (Figure 5.42).

Figure 5.42 Result Message after Invoking the Integration Flow


215

The screenshots for the input, as well as for the result message, are taken from a

SoapUI test client. The scenario is currently a synchronous scenario; otherwise

we wouldn’t have received a response back. However, where did we define tha

it should be a synchronous scenario? We actually didn’t. More mysterious is the

fact that the incoming message was built using a WSDL file containing the

description of an asynchronous interface. You can verify this by downloading th

associated WSDL file. Its name is SendOrderList_Async.wsdl, and can be down

loaded from www.sap-press.com/3979. You will find the following lines in the file

(Figure 5.43).

Figure 5.43 Definition of the Service's Operation

The operation consists of an input message, but no output message, which would

be needed for a synchronous interface. But why, then, is SAP HCI interpreting i

as a synchronous message exchange? Here’s the secret: it’s not SAP HCI tha

makes it a synchronous call, but rather the SOAP channel shown in Figure 5.40So, it makes sense to take a closer look at the SOAP adapter’s configuration

(Figure 5.44).

Figure 5.44 Configuration of the SOAP Channel in the Demo Scenario

Advanced Integration Scenarios5 Asynchronous Message Handling




216

Only the Address field is set with a string that will be used to create the URL for

invoking the integration flow. Besides that, you will find no information about

synchronous or asynchronous message handling at all. So what should the chan-

nel do once it receives a message from a client? It knows absolutely nothing about

the data that arrives at its address. It knows nothing about how the data it

receives was constructed nor whether it is based on a synchronous or asynchro-

nous WSDL file.

NoteThe WSDL file was just used in the SoapUI client to create a proper input message.

However, the WSDL file was never used in any of the SAP HCI configuration steps for

that scenario. Hence, SAP HCI knows nothing about the data it should process. This is

the payload-agnostic behavior of Apache Camel we talked about in previous chapters.

You can actually push anything to SAP HCI: it would work as long as you don’t have pro-

cessing steps in your route that rely on a specific format.

As the channel doesn’t know whether the received message should be treated

synchronously or asynchronously, it switches automatically to default mode.

Default mode for the SOAP channel means it will handle all messages synchro-

nously, and therefore sets the MEP field in the exchange to InOut. Voilà—this

explains the synchronous behavior of our scenario. So, the message walks

through the steps of the integration flow, and we have a resulting message cre-ated at the end of the chain when we reach the End event (see Figure 5.40). Here,

some magic happens: as there is no additional step to process, the last status of

the message’s body will be copied automatically into the body of the exchange’s

Out message. Remember: synchronous messages in an exchange have both an In

and an Out message, and the reply needs to be in the Out message. The Out mes-

sage (including body, headers, and attachments) is finally returned to the caller.

The next question is: can we make the route behave asynchronously? Yes, we can.

We merely have to make the SOAP channel aware of the concrete message it

receives. For this, the configuration of the SOAP channel provides a dedicated

field named URL to WSDL (see Figure 5.44). It allows us to point to our WSDL.

Simply click on Select. In the upcoming dialog box, Select WSDL Resource, click

on the button Upload from File System (Figure 5.45).


217

Figure 5.45 Adding a WSDL File to the SOAP Channel

The normal file picker dialog opens. Select the file SendOrderList_Async.wsdl from

your file system. The final configuration of the SOAP adapter including the link to

the WSDL file should look like the one shown in Figure 5.46.

Figure 5.46 Configuration of SOAP Adapter after Assigning the WSDL File

Save and deploy your change. By adding the WSDL file to the SOAP channel’

configuration, correct asynchronous message handling can be ensured. The chan

nel now knows that it receives an asynchronous XML message, compliant to the

WSDL, and will set the MEP field of the exchange to InOnly. However, a valida

tion of the incoming message against the WSDL is not done for the incoming

data. SAP HANA Cloud Integration provides a dedicated processing step for tha

purpose: the XML Validator, which requires the assignment of a WSDL file in its

configuration.Once deployed, you can invoke your integration flow again from your SOAP

test client of choice. If you are using SoapUI, you will get nothing back as reply





218

message. You will only receive acknowledgement from SAP HCI about the suc-

cessful reception of the message as an HTTP response code 202 (Figure 5.47).

Figure 5.47 Returned Header from SAP HCI after Invoking an Asynchronous Route via SOAPChannel

But what happened to our message inside SAP HCI? Where can we track this, now

that we don’t have SoapUI showing the result? For this, simply navigate to SAP

HCI’s message monitor by clicking on the three horizontal bars in the upper left

corner and choosing Monitor from the dropdown menu (Figure 5.48).

Figure 5.48 Switching to SAP HCI's Monitoring Environment

The monitoring dashboard opens. Click on the tile for the successfully completed

integration flows in the Message Monitor area of the screen (Figure 5.49).

In case this tile isn’t available in your monitoring dashboard by default, you can

easily create it by clicking on the tile with the + icon inside (also visible in Figure

5.49). Once done, the Tile Settings dialog opens (Figure 5.50), which allows you

to define respective filters via the Status, Time, and Integration Flow drop-

down lists (in Figure 5.50, the details of the Status dropdown list are also

shown). Select the entries fitting your needs and click on OK to confirm. The

newly configured tile will then automatically appear on the monitoring dash-board.


219

Figure 5.49 Tile for Switching to the Monitor of Completed Messages

Figure 5.50 Creating Your Own Tile on the Monitoring Dashboard

Once you have clicked on the tile for successfully delivered messages, you wil

receive an appropriate list sorted by date and time (see Figure 5.51, left half of the

screen). You also see the details of the message’s processing steps for the first

message in that list on the right half of the screen. By clicking on the Completed

link of your successfully finished message (Figure 5.51), you will switch to fullpage mode for the message’s processing steps within SAP HANA Cloud Integra

tion. In case of errors you would open the Failed Messages tile in Figure 5.49





220

and click on a Failed link instead, but the navigation and the information you see

will be the same. Make yourself familiar with the message processing log to use it

for root cause analysis in erroneous situations. You will find additional informa-

tion about the Message Monitor in Chapter 7.

Figure 5.51 Navigating to the Successfully Completed Message within the Message Monitor

Note

The SOAP channel supports both communication styles: synchronous and asynchro-nous. You have now seen how to influence its behavior. This is not the case for all

adapters. The SFTP adapter, for example, supports asynchronous message handling

only. Hence, it will merely support InOnly as entry in the MEP field. Consequently,

communication styles are highly adapter dependent and differ from adapter to adapter.

5.3.2 Adding an Asynchronous Receiver

Now that we know how to make a SOAP invocation asynchronous, we probably

also want to deliver the message to an asynchronous receiver, in order to really

verify the correct content of the received message. To keep administration effort

to a minimum, we will make use of an email receiver. All you need to complete

this exercise is a publically accessible email account. Here are the modeling steps

you have to complete in order to run the scenario with an email receiver:

1. Add a Receiver to the model on the right side of the integration flow. You find

the receiver besides the participant’s node in the palette (Figure 5.52).


22

Figure 5.52 Selecting a Receiver from the Palette

2. Position theReceiver on the right side of the Integration Process, close to the

message End event (Figure 5.53).

Figure 5.53 Positioning of the Receiver Pool Close to the End Event

3. Connect the End event with the Receiver1 pool (Figure 5.54).

Figure 5.54 Connecting End Event with the Receiver Pool

4. In the upcoming Adapter Type dialog, pick the Mail entry (Figure 5.55).

Figure 5.55 Picking the Email Adapter




g

222

5. Finally, configure the adapter according to your email account. The values

shown in the screenshots (Figure 5.56 and Figure 5.57) fit for a Google email

account. For more details on how to configure the email adapter, take a look at

the online documentation of SAP HANA Cloud Integration at https://cloudinte-

gration.hana.ondemand.com/PI/help, and then select “Designing and Managing

Integration Content.”

Figure 5.56 Configuring the Mail Adapter—General Tab

Figure 5.57 Configuring the Mail Adapter—Connection Tab

y g g

223

These configuration fields are self-explanatory. However, one field needs furthe

explanation: the Credential Name field, as shown in Figure 5.57. The field con

tains a simple string which refers to a deployed credentials artifact on the SAP

HCI server. You cannot define the username and password directly on the config

uration screen: it is necessary to deploy the credentials containing the username

and password on the server explicitly. This step is necessary for connections with

basic authentication needs, as is the case for the email connection. When deploy

ing the credentials on the server, you must provide a unique name (such as

FirstnameLastname, in our case) for reference purposes. This is the exact name you have to fill in the Credential Name field. If you have the rights for deploying

(ask your tenant administrator), you can execute the steps described in the note

box "Create User Credentials Artifact". For further details, see also the description

in the SAP HCI Documentation at https://cloudintegration.hana.ondemand.com/PI

help. Enter the URL, then select the document “Operating SAP HCI” and navigate

to the paragraph entitled “Deploying an Artifact”.

Create User Credentials Artifact

To enable the tenant to connect to the email receiver using the credentials of the email

account owner, you must add a Credential Name in the mail adapter of your integration

flow, which at this point is little more than a placeholder for an artifact that we will cre-

ate using the steps outlined below:

1. Choose the Monitor tab of the Web UI (compare Figure 5.48).

2. Select the Security Material tile under Manage Security Material.

3. ChooseAdd User Credential (see Figure 5.58).

4. Specify the properties of the User Credentials artifact. For Name, enter the value

that you entered in the Credential Name field in the Mail adapter (see Figure 5.57).

For User, enter your email box username, and as Password/Repeat Password enter

the associated password. Leave the SuccessFactors checkbox deselected. This set-

ting is only relevant when you define credentials to be used when connecting to a

SuccessFactors system (see Figure 5.59).

5. Click OK.

Figure 5.58 Adding a User Credential Artifact




224

Figure 5.59 Properties of a User Credentials Artifact

How Secure Are Your User Credentials?

You have now defined an artifact which contains the credentials that are used by the

tenant to connect to your email account using the mail adapter. Configuring the inte-

gration scenario, it was not necessary to share these credentials (username and pass-

word) with anyone. In the mail adapter settings, only an alias ( Credential Name) is

specified, which the other participants of your integration team sharing the same tenant

can see without any risk of a security leak.

Another artifact type, which is handled in the same way, is the Secure Parameter arti-

fact which is required for scenarios including the social media adapters (Twitter and

Facebook adapter, see Chapter 8, Section 8.3.6) and when you use the Adapter Devel-

opment Kit (see Chapter 6, Section 6.3).

If you don’t have deployment rights, ask the tenant administrator to take over the

process for you.

Note

The definition of the Mail Body field makes use of Camel’s Simple Expression Language.

We are explicitly accessing the In message of the exchange and taking its body, which

contains nothing else than the message’s payload, which is exactly what we want to see

in our email.

The final scenario should look similar to the one depicted in Figure 5.60. You can

easily identify the sender on the left, the message processing steps in the middle,

225

and the final receiver on the right. That’s the advantage of a graphical environ

ment: it clearly and intuitively describes how the message arrives at the server

how it is handled within the SAP HCI server, and to which systems using which

channels it is forwarded.

Figure 5.60 Asynchronous Integration Flow with Email Receiver

Once you have finished your configurations, you can run the scenario again. Thi

time, the message will be delivered to your email account. You should receive an

email containing the three order numbers. A screenshot of the email’s content i

shown in Figure 5.61.

Figure 5.61 Content of Received Email

Troubleshooting

If you are using a Google email account, as we have done in the exercise, consider the

following:

You might need to temporarily allow less secure apps to access your account. Other-

wise, Google email will refuse your connection attempt via SAP HANA Cloud Inte-

gration. Note that this is just for test purposes. You should revert back the setting in

your Google email account once you have verified the sending of emails via SAP HCI.More details can be found on the Internet. Search for “Google email allow less secure

apps to access your account” or directly navigate to https://support.google.com/

accounts/answer/6010255.




226

If you receive an error message, such as “javax.net.ssl.SSLHandshakeException:

unable to find valid certification path to requested target,” the reason is a miss-

ing certificate. You have to add the Google certificate to your key store sys-

tem.jks on you SAP HCI tenant. This certificate is needed for authorization pur-

poses. The valid certificate can be found on the Google web page at https://

pki.goog le.com/ . If you don’t have access rights to your key store, let the tenant

administrator do it for you. More on the key store can be found in Chapter 8.

Synchronous and asynchronous message handling procedures are at the core of

every integration solution, and SAP HANA Cloud Integration is no exception

from this rule. At the end of this chapter, you learned more about the internal

message processing details of SAP HCI. You have seen how synchronous and

asynchronous message handling can be controlled for the SOAP channel and how

an asynchronous receiver can be added to your scenario. The SAP HCI Monitor

was finally used to help you in tracking the message processing within SAP HCI.

You are now well-equipped to run your own asynchronous integrations in your

company.

5.4 Summary

Congratulations! You have mastered another important chapter on your journey through the world of integration using SAP HANA Cloud Integration. We imple-

mented more sophisticated integration scenarios comprising steps for content-

based message routing and managing of messages containing lists of entries. You

applied the splitter pattern to create individual messages out of the list and used

the gather pattern to aggregate the individual messages back into one reply mes-

sage. At the end of the chapter, you also learned how to influence synchronous

and asynchronous message handling for the SOAP adapter and how to add an

asynchronous receiver to your integration flow. This knowledge allows you to

play around with SAP HCI’s more advanced features. However, our journey con-

tinues: the next chapter will reveal even more secrets about the timer-based start

of integration flows, the structuring of large flows using modularization, and,

finally, about developing new adapters for SAP HCI.



7

Contents

Foreword by Bernd Leukert ..................................... ........................ ................. 13

Preface ..................... ........................ ........................ ........................ ................ 17

Acknowledgments ....................... ........................ ....................... ...................... 23

1 Introduction to SAP HANA Cloud Integration .......................... 27

1.1 The Role of SAP HANA Cloud Integration in a Cloud-Based

Strategy ........................ ........................ ........................ ................. 28

1.2 Use Cases ...................................................................................... 31

1.2.1 Point-to-Point Versus Mediated Communication ............. 31

1.2.2 Message-Based Process Integration .................................. 32

1.2.3 Cloud-To-Cloud Integration ............................................. 34

1.2.4 Cloud-To-On-Premise Integration .................................... 35

1.2.5 On-Premise-To-On-Premise Integration ........................... 35

1.2.6 Hybrid Usage of Cloud and On-Premise Integration

Solutions .......................................................................... 37

1.3 Capabilities .................................................................................... 38

1.3.1 Integration Platform-As-A-Service .................................... 38

1.3.2 Message Processing Step Types (Integration

Capabilities) ..................................................................... 39

1.3.3 Connectivity Options ........................................................ 411.3.4 Prepackaged Integration Content ..................................... 42

1.3.5 Security Features .............................................................. 44

1.3.6 High Availability ............................................................... 44

1.3.7 Integration Design and Monitoring Tools ......................... 45

1.4 Editions ......................................................................................... 45

1.5 Summary ....................................................................................... 47

2 Getting Started ......................................................................... 49

2.1 Architecture Overview ................................................................... 49

2.1.1 Virtual and Clustered Integration Platform ....................... 50

2.1.2 Detailed Structure of a Cluster .......................................... 56

2.1.3 Secure Communication .................................................... 59

2.1.4 Implementation of Message Flows ................................... 592.1.5 Architecture Summary ...................................................... 63

Contents Content



8

2.2 Tools and Processes ....................................................................... 67

2.2.1 Tools ................................................................................ 67

2.2.2 Processes ......................................................................... 72

2.3 Running Your First Integration Scenario ......................................... 73

2.3.1 Demo Scenario and Landscape ......................................... 73

2.3.2 Prerequisites .................................................................... 75

2.3.3 Set up the Landscape and the Technical Connections ....... 75

2.3.4 Develop the Integration Flow ........................................... 77

2.3.5 Send the SOAP Message .................................................. 88

2.3.6 Monitor the Message ....................................................... 902.3.7 Groovy Script ................................................................... 92

2.4 Summary ....................................................................................... 95

3 Integration Content Catalog ..................................................... 97

3.1 Introduction to the Integration Content Catalog ............................ 97

3.2 Consuming Prepackaged Content .................................................. 101

3.2.1 Search in the Integration Content Catalog ........................ 101

3.2.2 Import Prepackaged Integration Content .......................... 106

3.2.3 Modify or Configure Integration Package .......................... 107

3.2.4 Deploy Content ................................................................ 116

3.3 Terms and Conditions of Using Prepackaged Integration Content ... 117

3.3.1 Quick Configure versus Content Edit ................................ 117

3.3.2 Notify About Update ........................................................ 1183.4 Prepackaged Content Provided by SAP .......................................... 120

3.4.1 Content for SAP SuccessFactors ........................................ 121

3.4.2 Content for SAP Cloud for Customer ................................ 123

3.4.3 Content for Integrating with the SAP Ariba Network ........ 125

3.4.4 Content for Globalization Scenarios .................................. 127

3.5 Creating Your Own Content Package ............................................. 128

3.6 Summary ....................................................................................... 132

4 Basic Integration Scenarios ....................................................... 133

4.1 Working with SAP HCI’s Data Model ............................................. 133

4.1.1 Message Processing: The Apache Camel Framework ......... 135

4.1.2 Exercise: Working with Camel’s Message Model .............. 138

4.1.3 Connecting and Configuring a Sender withIntegration Flow ............................................................... 140

4.1.4 Adding and Configuring Steps in the Integration Flow ...... 143

9

4.1.5 Running the Integration Flow ........................................... 148

4.1.6 Troubleshooting ............................................................... 151

4.2 Content Enrichment by Invoking an OData Service ........................ 153

4.2.1 The Target Scenario .......................................................... 154

4.2.2 Invoking an OData Service ............................................... 155

4.2.3 Configuring the OData Connection ................................... 157

4.2.4 Creating the Resource Path Using the Query Editor .......... 160

4.2.5 Using the Content Enricher Step ....................................... 167

4.3 Working with Mappings ................................................................ 168

4.3.1 The Scenario .................................................................... 1704.3.2 Applying the Mapping Step in the Message Processing

Chain ............................................................................... 171

4.4 Summary ....................................................................................... 179

5 Advanced Integration Scenarios ............................................... 181

5.1 Message Routing ........................................................................... 181

5.1.1 The Scenario .................................................................... 182

5.1.2 Configuration of the Content-Based Router ...................... 184

5.1.3 Running the Content-Based Router Scenario .................... 189

5.2 Working with Lists ......................................................................... 192

5.2.1 The Scenario .................................................................... 192

5.2.2 Configuring the Integration Flow ...................................... 194

5.2.3 Running the Integration Flow ........................................... 2045.2.4 Enriching Individual Messages with Additional Data ......... 208

5.3 Asynchronous Message Handling ................................................... 211

5.3.1 Synchronous vs. Asynchronous Communication from

SAP HCI’s Perspective ...................................................... 212

5.3.2 Adding an Asynchronous Receiver .................................... 220

5.4 Summary ....................................................................................... 226

6 Special Topics in Integration Development .............................. 227

6.1 Timer-Based Message Transfer ....................................................... 227

6.1.1 The Scenario: Retrieving Weather Information for

a City Every Morning ........................................................ 228

6.1.2 Configuring a Time-Based Integration Flow ...................... 229

6.1.3 Invoking a SOAP-Based Web Service ................................ 2326.1.4 Running the Integration Flow ........................................... 239

6.2 Structuring of Large Integration Flows ........................................... 240

6.2.1 Getting a Hold of Complexity by Modularization .............. 240

Contents Content



10

6.2.2 Configuring the Collaboration between Parent and

Child Processes ........ ........................ ....................... ......... 242

6.3 Developing Adapters Using the Adapter Development Kit ............. 249

6.3.1 The Adapter Development Kit (ADK) ............................... 250

6.3.2 Installing the Adapter Development Kit ............................ 251

6.3.3 Developing a CMIS-Adapter ............................................. 255

6.3.4 Create an Adapter Project ................................................ 256

6.3.5 Bundle Adapter Jar(s) and Required Metadata .................. 257

6.3.6 Build and Deploy Adapter Project .................................... 261

6.3.7 Working with the Alfresco CMIS server ............................ 2636.3.8 Using Your New Adapter in an Integration Scenario ......... 267

6.4 Summary ....................................................................................... 275

7 SAP HCI Operations .................................................................. 277

7.1 SAP HCI Operations: Overview ...................................................... 278

7.2 Monitoring SAP HCI ...................................................................... 280

7.2.1 Monitor Message Processing ............................................ 282

7.2.2 Manage Integration Content ............................................ 291

7.2.3 Security Material .............................................................. 294

7.2.4 Managing Certificate-to-User Mappings ........................... 298

7.3 Summary ....................................................................................... 301

8 SAP HCI Security ....................................................................... 303

8.1 Technical System Landscape .......................................................... 304

8.1.1 Architecture ..................................................................... 304

8.1.2 Network Infrastructure ..................................................... 308

8.1.3 SAP Data Centers ............................................................. 310

8.1.4 Data Storage Security ....................................................... 311

8.1.5 Data Protection and Privacy ............................................. 312

8.2 Processes ....................................................................................... 314

8.2.1 Software Development Process ........................................ 315

8.2.2 Provisioning and Operating SAP HCI Clusters by SAP ....... 315

8.2.3 Customer Onboarding Process ......................................... 316

8.3 Data and Data Flow Security ......................................................... 318

8.3.1 Basic Cryptography in a Nutshell ...................................... 318

8.3.2 Transport-Level Security Options ...................................... 3248.3.3 Authentication (and Authorization) Options ..................... 325

1

8.3.4 Message-Level Security Options ....................................... 329

8.3.5 Securely Connecting a Customer System to SAP HCI

(Through HTTPS) .............................................................. 334

8.3.6 Setting up a Scenario Using OAuth With the

Twitter Adapter ................................................................ 343

8.3.7 Designing Message-Level Security Options in an

Integration Flow ............................................................... 348

8.4 User Administration and Authorization .......................................... 363

8.4.1 Technical Aspects of User Management ........................... 363

8.4.2 Personas, Roles and Permissions ....................................... 3648.4.3 Managing Users and Authorizations for an

SAP HCI Account ........................ ........................ ............. 365

8.5 Summary ....................................................................................... 368

9 Productive Scenarios Using SAP HCI ........................................ 369

9.1 SAP Financial Services Network ..................................................... 369

9.1.1 Overview of Capabilities ................................................... 370

9.1.2 Technical Landscape ......................................................... 371

9.1.3 Usage of Standard Messages ............................................ 373

9.1.4 SFTP Connectivity ............................................................ 373

9.2 Integration of SAP Cloud for Customer and SAP ERP ..................... 375


9.2.2 Example Adapter Configurations ...................................... 3779.3 Integration of SAP Cloud for Customer with SAP S/4HANA

Cloud Enterprise Edition ................................................................ 380

9.4 Integration of SAP SuccessFactors and SAP ERP ............................. 381


9.4.2 SAP SuccessFactors Adapter ............................................. 383

9.5 Integration of SAP Applications with the SAP Ariba Network ........ 386


9.6 Summary ....................................................................................... 388

10 Outlook ..................................................................................... 389

10.1 Integration Content Management .................................................. 390

10.1.1 Enhancements of the Catalog ........................................... 391

10.1.2 Transport Management .................................................... 39110.2 Partner Adapter Support ................................................................ 391

10.3 API Support ................................................................................... 392

Contents



12

10.4 B2B Support .................................................................................. 393

10.4.1 Additional Connectivity and Standards Support ................ 393

10.4.2 SAP Integration Advisor ................................................... 393

10.5 Messaging Service ......................................................................... 394

10.6 Hybrid Deployments ...................................................................... 395

10.7 Security ......................................................................................... 395

10.8 Applications Supported by SAP HCI ............................................... 396

10.9 Summary ....................................................................................... 396

Appendices ....................................................................................... 397

A Abbreviations ........................................................................................... 399

B Literature ................................................................................................. 405

C The Authors ............................................................................................. 409

Index ........................ ....................... ........................ ....................... ................. 411



41

Index

A

Absolute path, 198, 202, 205 Account

dashboard, 301member , 366

Actions, 119

Adapter, 108, 125, 126 Ariba adapter , 42 Facebook adapter , 42 HTTP adapter , 42 IDoc (SOAP) adapter , 41mail adapter , 42OData adapter , 42

SFTP adapter , 42 SOAP adapter , 41

SuccessFactors adapter , 42Twitter adapter , 42type, 156, 221, 235

Adapter Development Kit, 249, 250, 251, 273 Adapter development process, 249, 255, 257 Adapter metadata, 256, 257, 258, 259,

260, 270

Adapter-specific endpoints, 107 ADK, 250, 251, 258, 262, 273 Aggregation algorithm, 201 Apache Camel, 33, 61, 135, 136, 138, 146,

147, 150, 151, 163, 169, 182, 191, 213,216, 240, 250, 258Camel route, 63

Apache Chemistry client API, 258 Application edition, 45 Application ID, 283 Ariba, 121 Ariba Network, 43, 125, 126, 127, 386

content, 125 Artifact, 98, 104, 105, 106, 108, 110, 112,

117, 119, 128, 130

details, 293keystore, 349

Asymmetric key technologies, 319 Asynchronous communication, 179 Asynchronous message handling, 137, 211 Asynchronous receiver, 220, 226

Atom, 159, 165, 170 Attachment, 136, 284 Attribute group, 260 Audit log, 313 Authentication, 142, 158, 326

basic authentication, 326client certificate-based, 326

OAuth, 327type, 142, 195

Authorization, 326 Authorization group, 306, 364

assign to user , 367business expert, 364integration developer , 364

system developer , 364tenant administrator , 364

B

Basic authentication, 142, 150, 155, 195, 223Body, 144, 146, 150, 153, 184, 186, 216,

224, 246

BPMN, 134, 135, 183Bug fixes, 279Build adapter project, 261Bulk message, 201Bundle, 105

items, 105Business Process Model and Notation, 134Business-to-business integration, 30

C

C4C, 123, 124Camel component, 250, 251, 255, 256,

258, 273Cancel message, 284Canceled, 283, 291

CBR, 182, 183, 184, 188, 189, 191, 192, 238,242, 246

Certificate, 294

chain, 323

Index Inde



412

Certificate (Cont.)

distinguished name, 324 signing request, 340 X.509, 323

Certificate-to-user mapping, 298, 299,301, 327

adding , 300Certification authority, 323, 341Channel, 142, 157Cheat sheet, 255, 256Child process, 242, 244, 246

Children nodes, 287Client certificate, 158Cloud, 35

computing benefits, 28on-premise integration, 35

platform, 278

strategy, 30Cluster, 307

nodes, 52tenant cluster , 56

CMIS, 249, 251, 255, 258, 259, 260, 26 3, 264,265, 266, 267, 268, 269, 270, 271, 272,273, 274adapter , 250, 251, 255, 258, 260, 271, 272Camel component, 258

server , 250, 263, 264, 266, 267, 268, 270

CMS, 249, 250, 255, 256, 258, 263Collapse, 284, 293Comma separated values, 170Communication, 30, 307

inbound, 349

outbound, 349Communication pattern

pull pattern, 375 push-push, 374

Completed, 283, 290, 291

messages, 288Condition expression, 247Configure, 112Configure-only, 107, 111, 112, 113, 117, 120Connection, 72

type, 141Connectivity, 41Connector, 141Content

Ariba network, 125

Content (Cont.)

globalization scenarios, 127 SAP Cloud for Customer , 123 SuccessFactors, 121

Content edit, 107, 117, 118conditions, 117

Content enricher, 153, 167, 168Content filter, 233, 238Content for globalization scenarios, 121Content Management Interoperability

Services, 249

Content Management System, 249Content modifier, 40, 115, 135, 143, 144,

145, 147, 150, 155Content package

update, 119Content publisher, 98Content reviewer, 98Content type, 159, 165Content-based

router , 33, 233routing , 179, 182

ContextName, 287Country, 102CPU, 278Create an adapter project, 256Create user credentials artifact, 223

Credential name, 223, 224Credentials, 294CSV, 170Custom adapter, 227Customer workspace, 106, 116Cxf.*, 287

D

Data flows, 108Data integration, 130Data model, 133, 138Data protection, 312

customer onboarding , 313dialog user access, 313

European General Data Protection Regulation, 314

message content, 311monitoring data, 313

413

Data storage, 306Database, 40Decryption, 320Default gate, 184Default route, 188, 189Delete, 293Deploy, 109Deploy new security artifacts, 296Deployed, 296

artifacts, 263, 268, 269by, 292

on, 292Deploying, 296Deployment, 148

fast, 29Design, 100, 106, 112, 128

view, 138workspace, 112

Detailed log, 286Developer Edition, 46Developing adapters, 249Digest, 331Digital certificate, 322Digital decryption, 330Digital encryption, 44, 330Digital signature, 44, 331Discover, 100, 101

Documents, 105, 130Download, 293, 298Download artifact, 294Download logs, 286

E

Eclipse, 133, 251, 252, 253, 255, 256, 257,261, 268, 273

Eclipse Luna, 251, 253Edit mode, 140EDMX, 159, 164, 165eDocument

Chile, 127 Hungary, 127 Italy, 127 Peru, 127

Spain, 127eDocument Framework, 127

Email, 136Email receiver, 220, 223Empty start event, 244Encryption, 319, 320End event, 135Endpoint, 88, 148, 236, 237, 293Endpoint URL, 149Enricher pattern, 193Enterprise integration pattern, 33

example, 33Enterprise integration patterns, 182

Enterprise Services Builder, 171, 193Enterprise Services Repository, 169Entity Data Model XML, 159Error, 283, 287, 290, 291, 296

analysis, 153message, 153, 288

Escalated, 283, 290, 291ESR, 169, 171, 175Evaluation condition, 185Evaluation sequence, 191, 192Event, 40Exception, 137Exchange, 136, 137, 144, 146, 147, 153, 212,

213, 216, 217, 224, 241, 242, 245, 249, 272Exchange ID, 137Exchange property, 137, 138, 144, 145, 146,

147, 150, 153, 241, 243Exclusive gateway, 183, 189, 246Execution sequence, 190, 191, 200Expand, 284, 293Expression type, 186, 187, 188External call, 244Externalized parameter, 114, 115, 116

F

Failed, 283, 290, 291

messages, 288Failover, 57Field mapping, 175File, 108, 130Flexible pipeline, 138, 240

Index Inde



414

G

Gateway, 242Gather, 193, 194, 201, 203, 204, 208,

209, 210Gather/merge pattern, 193General splitter, 195, 196, 197Globalization scenarios, 127

government formats, 127Graphical mapper, 175

H

Hash function, 331Hash value, 331Header, 136, 138, 144, 145, 150, 153, 155,

183, 186, 187, 201, 205, 241variable, 242, 247

Health check, 44, 278, 301High availability, 57

failover , 57HTTP, 249HTTPS, 44, 324

connection, 307Hybrid deployment, 28

I

Identity provider, 364IDoc, 249

adapter , 377 splitter , 197

Industries, 102Innovation

fast, 29InOnly, 137, 213, 217, 220InOut, 137, 213, 216Integration, 28, 29Integration artifact, 59

integration flow, 59, 63Integration bus, 32, 39Integration content, 43

artifacts, 105

consume, 106deploy, 109

Integration content (Cont.)

design, 69documents, 105

perform an update, 119 preconfigured, 30 predefined, 42tags, 105terms & conditions, 107

Integration Content Catalog, 97, 98, 99, 100,101, 102, 103, 106, 114, 117, 118, 120,122, 123, 124, 125, 127, 128, 132

accessing , 99catalog , 98content, 98

discover , 100existing package, 102

packages, 98 prebuilt integration flows, 98 search, 101 show filter , 102templates, 98via a publicly accessible URL , 99via your own tenant, 99web-based application, 99

Integration content monitor, 148, 151Integration designer, 256Integration developer, 98

Integration engine, 145, 198, 213, 239, 240Integration flow, 52, 60, 108, 283, 287, 290

change, 108channel, 60connectivity details, 108

definition of , 60demo example, 73

deployment, 62design, 59display, 108download, 109history, 111name, 284, 285revert to an older version, 110

step, 60versions, 105, 109, 110, 111, 112, 113, 114,

115, 116, 117, 118, 125, 126Integration flow step

decryptor , 359encryptor , 361

415

Integration middleware

on-premise, 36Integration operations, 262, 268, 273Integration package, 43

configure, 107create, 128editor , 108latest, 102modify, 107

predefined, 35Integration pattern, 39

Integration platform, 30, 32, 38, 49, 50resources, 50virtual, 53virtualized, 50

Integration process, 134Integration use case

cloud-to-cloud integration, 381cloud-to-on-premise integration, 376

Integration-as-a-service, 39Interface determination, 138Intermediate error, 287Internet of Things, 227Invoke web service, 240Issuer DN, 300Iterating splitter, 196

J

JavaScript Object Notation, 170 JSON, 159, 170

K

Key PGP key pair , 354 private, 319 public, 319

Key pair generation of , 338

Keystore, 294, 298, 321Keystore explorer, 338Keyword, 102Kleopatra, 353

L

Last modified on, 300Last updated at, 284Line of business, 102List of entries, 192Load balancer, 54, 307, 334Local integration process, 243, 244, 245,

248, 249Local process, 240, 241, 242, 244, 245Locks, 108

Log current payload, 288Log details, 282Log entry, 153Log view, 286

M

Manage integration content, 281, 291,292, 294

Manage security material, 279, 281, 299 Manage user and roles, 278, 280 Managing certificate-to-user mappings, 298 Managing tiles, 288 Mapping, 40, 138, 168

editor , 172, 173, 175, 176

engine, 169 step, 168

Mediated communication, 32 Mediation engine, 136 Memory, 278 MEP, 137, 216, 217, 220 Message

exchange, 50 Message content, 58, 311 Message exchange, 28, 30, 39

pattern, 137, 213 Message flow, 134 Message format

ISO 20022 standard, 373 Message header, 115, 243, 246 Message model, 138

Message monitor, 151, 218, 220, 283 Message persistence, 40 Message processing, 49, 286

Index Inde



416

Message processing log, 58, 153, 220, 286

protection of , 313 Message protocol, 141, 235 Message routing, 181 Message start event, 270 Message transformation, 40 Message type, 175 MessageGuid, 283, 287 Messaging service, 57 Metadata, 128 Microservice, 63

Modifiable, 120 Modified by, 300 Modularization, 240 Monitor, 100, 148, 151, 280, 281, 282, 284,

291, 294, 299 Monitoring, 45, 58, 69, 90

data, 311integration contents, 280runtime messages, 279

SAP HCI , 279 Monitoring screen

overview, 281 MPL, 286, 287

properties, 287 Multi-mapping, 202 Multi-select mode, 284

Multi-tenancy, 39, 44, 51

N

Name, 292Namespace, 207, 208, 233, 234, 237

mapping , 238, 239, 240Network, 308

demilitarized zone, 308

sandboxed segment, 309 segment, 308

Node, 287central management node, 310node failure, 57

runtime node, 54tenant management node, 54

Node explorer, 262Notify about update, 117, 118

O

OASIS, 255OAuth, 327, 343

credentials, 328Object management group, 134OData, 249

channel, 164connection, 157, 170, 209

service, 133, 153, 154, 155, 158, 159, 160,165, 168, 170, 173, 179, 181, 209

OMG, 134Onboarding, 370One-way message, 137, 213On-premise, 27, 35, 98Open Data Protocol, 153OpenCMIS Workbench, 264, 265, 266,

271, 272OSGi, 61, 258, 274, 275

Equinox, 61OSGi bundles, 258Out message, 137OverallStatus, 287Overlapping routing conditions, 189Overview, 108, 110, 112Own content package, 128

creating , 128

P

Package, 138additional options, 103copy, 104

summary of package, 103Package lock, 131Parallel processing, 200Parameters, 111, 112, 113, 114, 115, 116, 1 18Parent process, 242, 243, 244, 245, 246,

247, 248Participant, 156Passwords, 294Payload, 136, 169PGP key, user ID, 361PGP public keyring, 295, 350

deploy on tenant, 360

417

PGP secret keyring, 295, 350

deploy on tenant, 355 signer user ID, 362

PKCS#7/CMS splitter, 197Platform-as-a-service, 50Point-to-point communication, 31Pool, 134Prepackaged integration content, 101, 117,

119, 128consuming , 101import, 106

process of consuming , 101update, 117

Process call, 244, 245Processing, 283, 291

chain, 135, 150, 205time, 284

Product, 102 profiles, 279

Professional Edition, 46Project explorer, 257Proxy type, 158

Q

Query editor, 154, 159, 160, 161, 162, 163,

164, 165, 168, 170, 173Quick configure, 117, 118

R

Receiver, 108, 112, 113, 114, 118determination, 138

Relative path, 198Request message, 175, 178Request-reply, 155, 156, 157, 166, 167, 168,

170, 171, 177, 209, 228, 234Request-response message, 137Resource path, 159, 161, 162, 163, 165, 168Response message, 138, 145, 151, 166, 175Responsibility matrix, 278Result message, 147, 150Retry, 283, 290, 291

messages, 288

Role, 306, 364

ESBMessaging.send, 365, 368Root cause analysis, 220Root certificate

load balancer , 336Route, 135, 137, 150, 171Routing, 40, 169

condition, 183, 247rule, 189

Run once, 230, 239Runtime configuration, 207, 208

Runtime node, 57

S

SaaS administrator, 310, 316SAP BPM, 134SAP Business Process Management, 134SAP Cloud Connector, 37, 42, 158, 236SAP Cloud for Customer, 43, 106, 121, 123,

124, 125, 375content, 123

SOAP adapter , 125SAP Community Network, 75

user management, 364SAP data center, 44, 310

SAP ERP, 375SAP Financial Services Network, 313,317, 369

monitoring , 371using SAP Process Integration, 372

SAP Fiori, 380SAP FSN Business Cockpit, 371SAP HANA Cloud Account Cockpit, 365SAP HANA Cloud Integration, 28, 30, 49, 97 ,

277, 301

architecture, 64, 305SAP HANA Cloud Integration Edition, 45SAP HANA Cloud Platform, 50, 51

SAP HANA Cloud Platform Cockpit, 65,67, 306

tenant, 51user management, 363

SAP HCI, 277, 278, 279, 280, 288, 291, 292,294, 295, 296, 298, 299, 301connectivity options, 123

Index Inde



418

SAP HCI (Cont.)

day-to-day operations, 278maintenance, 278monitoring , 280monitoring capabilities, 277monitoring features, 280operational tasks, 278operations, 278

operations team, 315releases updates, 279

support, 278

SAP HCI Edition Developer Edition, 317

SAP HCM, 121, 122SAP ID Service, 364SAP Identity Service, 306SAP Integration Content Catalog, 35, 43, 67SAP MM, 125SAP PI, 134, 138, 168, 169, 171, 175, 178,

193, 202SAP Process Integration, 35, 134SAP Process Orchestration, 35, 278SAP S/4HANA, 380SAP S/4HANA Cloud Enterprise Edition, 380SAP SCN credentials, 99SAP Solution Manager, 134SAP SRM, 125

SAP Supplier Relationship Management, 125SAP Web Dispatcher, 377Scaling

horizontal, 39, 44Schedule on day, 230, 231Schedule to recur, 231, 232Scheduler, 112, 113Secure communication, HTTPS, 59Secure File Transfer Protocol (SFTP), 373Secure Parameter, 268, 269, 270, 295Secure Shell (SSH), 44, 325, 375Security, 40, 59

customer onboarding process, 316data storage security, 311

message-level, 329 physical, 310

software development process, 315transport-level, 318

Security material, 294, 295Security material management, 279

Security parameter, 268Security standard

OpenPGP, 333 PKCS#7, 332 S/MIME , 333WS-Security, 333

XAdES , 333 XML Signature, 333

Sender, 108, 112, 113, 114, 118Separation of concerns, 240Sequence flow, 147

Serial number, 300SFTP, 134, 249, 307SFTP adapter, 373Signature, 319Signing, 320Simple Expression Language, 146, 163,

187, 224Simple Mail Transfer Protocol, 325Simple Object Access Protocol, 134SMTP, 325SOAP, 134, 141, 148, 153, 154, 178, 183,

189, 195, 204, 212, 213, 215, 216, 217,218, 220, 226, 227, 228, 232, 234, 235,236, 237, 240, 241, 249

SOAP adapter, 141, 142, 237, 239, 240, 387

address, 84

WSDL, 84SOAP call, 228SOAP channel, 183, 215, 216, 217, 220, 226SOAP client, 75

authentication, 89SOAP data source, 227Software

maintenance, 39upgrade, 39

Software update, 45Software updates and maintenance, 279Software-as-a-service, 29Splitter, 193, 194, 195, 196, 197, 198, 199,

200, 201, 202, 203, 205, 206, 208, 209, 210 pattern, 193

Splitting tag, 197, 198SSH, 325SSH Known Hosts, 295, 375Standard

ISO/IEC 27001:2013, 314, 395

419

Standard Edition, 45Start event, 135, 141Start message event, 194Status, 283, 284, 287, 290Status per node, 292Stop on exception, 200Stored, 296Streaming, 199Structuring large integration flows, 240Subject DN, 300Sub-process, 240, 241, 242, 243, 244, 245,

246, 248, 275SuccessFactors, 43, 97, 121, 122, 123, 381

adapter , 123

content, 121discover all packagaes, 122

employee Central, 381integrates onboarding , 121OData API , 383query, insert, upsert, update, 385

SFAPI , 383SuccessFactors adapter, 383

query operations, 385Support

hardware and infrastructure, 278Supported platform, 102Symmetric key technology, 319

Synchronous communication, 153Synchronous interface, 174, 175Synchronous message handling, 137, 211Synchronous scenario, 150

T

Table settings, 284, 285, 293Tags, 105Talent management processes, 121Templates

copy, 106Tenant, 99, 100, 101, 108, 109, 111, 113

tenant isolation, 51Tenant administrator, 223, 224, 226, 365Tenant isolation, 304, 306

message processing , 307user management, 306

Tenant keystore, deploying of, 342

Tenant management node, 57Terms and condition, 107, 117Tile settings, 290Tiles, 280, 282, 288, 289, 291, 299Time, 283Time-based integration flow, 229Timeout, 199Timer start event, 228, 229, 230, 231, 232,

239, 240, 244Timer-based message handling, 227Timer-based message transfer, 227

TLS, 324Total cost of ownership

low, 30Trace log, 153Tracing, 280Transport Layer Security, 324Transport protocol, 324Troubleshooting, 151Twitter adapter, 344, 347Type, 292

U

Undeploy action, 294Undeploy integration flow, 273

Update available, 119Update package, 119Update page, 284, 293Upgrade, 29URI, 154, 159, 161URL, 108, 130, 154, 155, 166User credentials, 295User management, dialog user, 306User, technical user, 365Username, 294, 300User-to-role assignment, 306

V

Valid until, 300Value Mapping, 108, 130Value Mapping Migration helper tool, 125Verifying, 320Version, 292

Index



420

Version history, 111Virtual machine, 52

Java Virtual Machine, 52 Java Virtual Machine instance, 52

W

Weather service, 232Web of Trust, 323Web service invocation, 232

Web Services Description Language, 169Web UI, 65, 240, 251, 258, 268

security artifacts, 297Web-service, 136Working with lists, 192WSDL, 75, 144, 169, 171, 172, 174 , 178, 193,

215, 216, 217, 233, 236, 237, 238, 239, 240

X

XI adapter, 372XI message protocol, 372XML, 165, 169, 170, 171, 186, 187, 188, 192,

193, 201, 202, 208, 217, 233, 234, 239,240, 246, 247, 248, 258, 260envelope, 202request message, 234

schema definition, 169validator , 217

XPath, 146expression, 186, 198, 202, 203, 205, 207,

208, 233XSD, 164, 165, 169, 170, 171, 172, 173,

174, 178

First-hand knowledge.



First hand knowledge.

We hope you have enjoyed this reading sample. You may recommend

or pass it on to others, but only in its entirety, including all pages. This

reading sample and all its parts are protected by copyright law. All usage

and exploitation rights are reserved by the author and the publisher.

John Mutumba Bilay studied computer engineering

and finance at the University of Cape Town, South Af-

rica. After completing his studies, he started his career

as a software engineer. He currently works as a senior

software engineer and enterprise integration consul-

tant at Rojo Consultancy B.V. in the Netherlands. Withmore than 12 years of international experience in infor-

mation technology, he has primarily focused on integration technologies

for the last nine years. His SAP specialities include SAP integration- and

process-related technologies, including SAP Process Orchestration and

SAP HANA Cloud Integration.

Dr. Peter Gutsche studied physics at Heidelberg Uni-

versity, Ruperto Carola. After completing his Ph.D, he

joined SAP in 1999. As an information developer, Peter

was involved in many knowledge management projects

related to SAP‘s interface and integration technologies.

Today, as a knowledge architect, he is responsible for

the product documentation of SAP HANA Cloud Integ-

ration and works on documentation concepts for Cloud software.

Prof. Dr. Volker Stiehl studied computer science at the

Friedrich-Alexander-University of Erlangen-Nuremberg.

After 12 years as a developer and consultant at Sie-

mens, 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. He left SAP in 2016

and accepted a position as a professor at the Ingolstadt Technical Univer-

sity of Applied Sciences where he is currently teaching business infor-

matics.

John Mutumba Bilay, Peter Gutsche, Volker Stiehl

SAP HANA Cloud Integration420 Pages, 2016, $69.95ISBN 978-1-4932-1317-7

www.sap-press.com/3979

