In previous articles you have already used SAP HANA Cloud Integration (SAP HCI) as the cloud-based solution to reliably transfer messages between on-premise as well as on-demand enterprise applications. So far, the integration logic executed on SAP HCI was mainly triggered by incoming messages (e.g., an order request originating from a sender CRM system that needed to be routed to various back-end ERP systems, depending on the message’s content).

However, not all integration scenarios require an incoming message to trigger their behavior. Sometimes you want to check for existing data on a regular basis (e.g., retrieving the status of a machine or related-machine data in the Internet of Things world and forwarding the information to a Business Intelligence system for further analysis, or predicting the potential failure of the machine). Those scenarios require the initiation of a message transfer on a timely basis. I’ll dive into the details on how you can achieve this using SAP HCI.

The Scenario: Retrieving Weather Information Every Morning for a City

Assume you would like to get the current weather information for a certain city every morning at 7:00 am. The report should show up in your inbox allowing you to read it on your mobile phone during breakfast. This would allow you to take an umbrella in case of rain or decide on the right clothes for the day depending on the temperature. This is a typical scenario requiring a time-based start of the message transfer. Let’s take a look at the scenario and see what is required to implement it (Figure 1).

Figure 1

Integration flow for regularly retrieving weather information for a city from a publicly available web service

You will recognize the first difference compared to other integration flows discussed so far right at the start of the flow on the left. It starts with a new event called a Timer Start Event, indicated by the clock in the circular shape (). I’ll take a closer look at its configuration in a minute. The Timer Start Event is followed by a Content Modifier that takes care of preparing the input message for the Simple Object Access Protocol (SOAP) call to the external web service. The actual call is done by the Request-Reply step. It is connected via SOAP with the WeatherInfo service.

Once you receive the result back from the service, it is sent to the receiver via the Mail adapter. It shouldn’t be a problem for you to model the scenario based on the knowledge you have acquired so far by following my SAP Professional Journal SAP HCI article series. The only new shape in this integration flow is the Timer Start Event in the palette beneath the events main entry (). It is depicted in Figure 2 for your reference.

Figure 2

The Timer start event in the modeling palette

Let’s walk through the configuration of the scenario step by step.

Configuring a Time-Based Integration Flow

I begin with the configuration of the most important shape of the flow, the Timer Start Event. It is responsible for initiating the flow’s execution without requiring a dedicated start message. The configuration options are depicted in Figures 3 and 4.

Figure 3

Configuration of the Timer Start Event for a scheduled start on a certain day

Figure 4

Configuration of the Timer Start Event for a weekly recurring schedule

You have three options for starting the integration flow (Figure 3):

1. Run only once, immediately after deployment of the flow
2. Scheduled execution on a concrete day at a well-defined time (or well-defined times)
3. Recurring schedule on a daily, weekly, or monthly basis at a well-defined time (or well-defined times)

The Run Once option allows you to trigger the flow’s execution immediately after a successful deployment. This can also be used for testing purposes if you want to try out certain integration functionalities without sending incoming messages just to get the flow started. Obviously you don’t have to configure additional settings for this option as the exact point of time is given by the finalization of the flow’s deployment.

The second option, named Schedule on Day (shown in Figure 3), defines a concrete day on which the integration flow should run. In the On Date field you obviously enter the respective execution date. However, you can also specify either the one-time execution or a recurring execution on that particular date. If you want to run the flow only once, you have to set the On Time check box accompanied with a concrete time. For a recurring invocation of the flow’s logic, select the Every check box. In addition you have to define two intervals:

1. In which interval should the flow be activated: Every minute? Every hour? There are even other intervals possible, such as every second minute or every four hours. You select the respective interval from the drop-down list to the right of the Every check box.
2. Between which times of the day should the flow run? For this you can define the start and end times. The respective drop-down lists are positioned to the right of the Between label in Figure 3, the first representing the start time and the second the end time.

The settings in Figure 3 represent a recurring invocation of the integration flow on October 28, 2015. The flow will be called every minute in the time between midnight and 1:00 am. With the options explained above you can quite flexibly schedule the flow’s execution for a certain day. Even for that particular day you can define a recurring execution. However, the repetition of the invocation is limited to one day. In order to overcome this limitation, you want to make use of the third option, which allows you to define a more flexible period for the flow’s repetition.

For this purpose select the Schedule to Recur check box (Figure 4). The drop-down list beneath the label Schedule to Recur allows the definition of the period. Currently daily, weekly, and monthly repetitions are supported. Depending on your choice, you can further define these attributes:

• Daily: Define whether the flow should run only once on that day or recurring. You have exactly the same options described above for the Schedule on Day selection.
• Weekly: Define the days per week on which the flow should be invoked. The chosen days activate the flow every week. You even can pick several days, such as Monday and Friday or Wednesday through Saturday.
• Monthly: Specify the date on which the integration flow should run every month. You have the choice between 1 and 31. If a chosen date is not applicable for a certain month (e.g., 31 is not a valid date for February, April, June, September, and November), the flow is not executed. Only one day can be selected.

With the configuration shown in Figure 4 the integration flow is activated every week on Tuesdays and Thursdays. The flow runs on those days every four hours between 6:00 am and 6:00 pm. The time zone has been set to India Standard Time.

Obviously you have many configuration options to schedule the execution of your integration flows. The Timer Start Event is the element of choice for start, end, and recurring times, periods, and time spans. Coming back to the initial goal of receiving the weather information every morning at 7:00 am, the obvious configuration is the selection of the Schedule to Recur radio button with the identically named drop-down list set to Daily. In addition, select the On Time radio button and set the according time to 07:00 AM (Figure 5).

Figure 5

Setting the recurrence to every day at 7:00 am

However, there is an alternative approach possible, especially if you want to get the weather information only for workdays. In this case choose the Weekly entry from the Schedule to Recur drop-down list and set the check boxes for the required workdays (Monday to Friday in my example, as shown in Figure 6).

Figure 6

Setting the recurrence to workdays only

What you can configure for the Timer Start Event is quite impressive. You can benefit from the many configuration options to define your own schedule.

Invoking a SOAP-Based Web Service

Continue now with the invocation of a web service based on the SOAP protocol. You are using an external web service hosted on webservicex.net. It is a service returning weather information for a certain city. The service requires the city’s name and its country as inputs. More details can be found on the service’s homepage: https://www.webservicex.net/New/Home/ServiceDetail/56. On the homepage you will find the Web Services Description Language (WSDL) describing the web service as well as examples about its correct invocation. For your convenience I have included the WSDL file called globalweather.wsdl in Figure 7. You need to store it on your local computer and need it later for configuring the SOAP connection.

<?xml version="1.0" encoding="utf-8" ?> 
- <wsdl:definitions xmlns:tm="https://microsoft.com/wsdl/mime/textMatching/" xmlns:soapenc="https://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="https://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="https://www.webserviceX.NET" xmlns:soap="https://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="https://www.w3.org/2001/XMLSchema" xmlns:soap12="https://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="https://schemas.xmlsoap.org/wsdl/http/" targetNamespace="https://www.webserviceX.NET" xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/">
- <wsdl:types>
- <s:schema elementFormDefault="qualified" targetNamespace="https://www.webserviceX.NET">
- <s:element name="GetWeather">
- <s:complexType>
- <s:sequence>
  <s:element minOccurs="0" maxOccurs="1" name="CityName" type="s:string" /> 
  <s:element minOccurs="0" maxOccurs="1" name="CountryName" type="s:string" /> 
  </s:sequence>
  </s:complexType>
  </s:element>
- <s:element name="GetWeatherResponse">
- <s:complexType>
- <s:sequence>
  <s:element minOccurs="0" maxOccurs="1" name="GetWeatherResult" type="s:string" /> 
  </s:sequence>
  </s:complexType>
  </s:element>
- <s:element name="GetCitiesByCountry">
- <s:complexType>
- <s:sequence>
  <s:element minOccurs="0" maxOccurs="1" name="CountryName" type="s:string" /> 
  </s:sequence>
  </s:complexType>
  </s:element>
- <s:element name="GetCitiesByCountryResponse">
- <s:complexType>
- <s:sequence>
  <s:element minOccurs="0" maxOccurs="1" name="GetCitiesByCountryResult" type="s:string" /> 
  </s:sequence>
  </s:complexType>
  </s:element>
  <s:element name="string" nillable="true" type="s:string" /> 
  </s:schema>
  </wsdl:types>
- <wsdl:message name="GetWeatherSoapIn">
  <wsdl:part name="parameters" element="tns:GetWeather" /> 
  </wsdl:message>
- <wsdl:message name="GetWeatherSoapOut">
  <wsdl:part name="parameters" element="tns:GetWeatherResponse" /> 
  </wsdl:message>
- <wsdl:message name="GetCitiesByCountrySoapIn">
  <wsdl:part name="parameters" element="tns:GetCitiesByCountry" /> 
  </wsdl:message>
- <wsdl:message name="GetCitiesByCountrySoapOut">
  <wsdl:part name="parameters" element="tns:GetCitiesByCountryResponse" /> 
  </wsdl:message>
- <wsdl:message name="GetWeatherHttpGetIn">
  <wsdl:part name="CityName" type="s:string" /> 
  <wsdl:part name="CountryName" type="s:string" /> 
  </wsdl:message>
- <wsdl:message name="GetWeatherHttpGetOut">
  <wsdl:part name="Body" element="tns:string" /> 
  </wsdl:message>
- <wsdl:message name="GetCitiesByCountryHttpGetIn">
  <wsdl:part name="CountryName" type="s:string" /> 
  </wsdl:message>
- <wsdl:message name="GetCitiesByCountryHttpGetOut">
  <wsdl:part name="Body" element="tns:string" /> 
  </wsdl:message>
- <wsdl:message name="GetWeatherHttpPostIn">
  <wsdl:part name="CityName" type="s:string" /> 
  <wsdl:part name="CountryName" type="s:string" /> 
  </wsdl:message>
- <wsdl:message name="GetWeatherHttpPostOut">
  <wsdl:part name="Body" element="tns:string" /> 
  </wsdl:message>
- <wsdl:message name="GetCitiesByCountryHttpPostIn">
  <wsdl:part name="CountryName" type="s:string" /> 
  </wsdl:message>
- <wsdl:message name="GetCitiesByCountryHttpPostOut">
  <wsdl:part name="Body" element="tns:string" /> 
  </wsdl:message>
- <wsdl:portType name="GlobalWeatherSoap">
- <wsdl:operation name="GetWeather">
  <wsdl:documentation xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/">Get weather report for all major cities around the world.</wsdl:documentation> 
  <wsdl:input message="tns:GetWeatherSoapIn" /> 
  <wsdl:output message="tns:GetWeatherSoapOut" /> 
  </wsdl:operation>
- <wsdl:operation name="GetCitiesByCountry">
  <wsdl:documentation xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/">Get all major cities by country name(full / part).</wsdl:documentation> 
  <wsdl:input message="tns:GetCitiesByCountrySoapIn" /> 
  <wsdl:output message="tns:GetCitiesByCountrySoapOut" /> 
  </wsdl:operation>
  </wsdl:portType>
- <wsdl:portType name="GlobalWeatherHttpGet">
- <wsdl:operation name="GetWeather">
  <wsdl:documentation xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/">Get weather report for all major cities around the world.</wsdl:documentation> 
  <wsdl:input message="tns:GetWeatherHttpGetIn" /> 
  <wsdl:output message="tns:GetWeatherHttpGetOut" /> 
  </wsdl:operation>
- <wsdl:operation name="GetCitiesByCountry">
  <wsdl:documentation xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/">Get all major cities by country name(full / part).</wsdl:documentation> 
  <wsdl:input message="tns:GetCitiesByCountryHttpGetIn" /> 
  <wsdl:output message="tns:GetCitiesByCountryHttpGetOut" /> 
  </wsdl:operation>
  </wsdl:portType>
- <wsdl:portType name="GlobalWeatherHttpPost">
- <wsdl:operation name="GetWeather">
  <wsdl:documentation xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/">Get weather report for all major cities around the world.</wsdl:documentation> 
  <wsdl:input message="tns:GetWeatherHttpPostIn" /> 
  <wsdl:output message="tns:GetWeatherHttpPostOut" /> 
  </wsdl:operation>
- <wsdl:operation name="GetCitiesByCountry">
  <wsdl:documentation xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/">Get all major cities by country name(full / part).</wsdl:documentation> 
  <wsdl:input message="tns:GetCitiesByCountryHttpPostIn" /> 
  <wsdl:output message="tns:GetCitiesByCountryHttpPostOut" /> 
  </wsdl:operation>
  </wsdl:portType>
- <wsdl:binding name="GlobalWeatherSoap" type="tns:GlobalWeatherSoap">
  <soap:binding transport="https://schemas.xmlsoap.org/soap/http" /> 
- <wsdl:operation name="GetWeather">
  <soap:operation soapAction="https://www.webserviceX.NET/GetWeather" style="document" /> 
- <wsdl:input>
  <soap:body use="literal" /> 
  </wsdl:input>
- <wsdl:output>
  <soap:body use="literal" /> 
  </wsdl:output>
  </wsdl:operation>
- <wsdl:operation name="GetCitiesByCountry">
  <soap:operation soapAction="https://www.webserviceX.NET/GetCitiesByCountry" style="document" /> 
- <wsdl:input>
  <soap:body use="literal" /> 
  </wsdl:input>
- <wsdl:output>
  <soap:body use="literal" /> 
  </wsdl:output>
  </wsdl:operation>
  </wsdl:binding>
- <wsdl:binding name="GlobalWeatherSoap12" type="tns:GlobalWeatherSoap">
  <soap12:binding transport="https://schemas.xmlsoap.org/soap/http" /> 
- <wsdl:operation name="GetWeather">
  <soap12:operation soapAction="https://www.webserviceX.NET/GetWeather" style="document" /> 
- <wsdl:input>
  <soap12:body use="literal" /> 
  </wsdl:input>
- <wsdl:output>
  <soap12:body use="literal" /> 
  </wsdl:output>
  </wsdl:operation>
- <wsdl:operation name="GetCitiesByCountry">
  <soap12:operation soapAction="https://www.webserviceX.NET/GetCitiesByCountry" style="document" /> 
- <wsdl:input>
  <soap12:body use="literal" /> 
  </wsdl:input>
- <wsdl:output>
  <soap12:body use="literal" /> 
  </wsdl:output>
  </wsdl:operation>
  </wsdl:binding>
- <wsdl:binding name="GlobalWeatherHttpGet" type="tns:GlobalWeatherHttpGet">
  <http:binding verb="GET" /> 
- <wsdl:operation name="GetWeather">
  <http:operation location="/GetWeather" /> 
- <wsdl:input>
  <http:urlEncoded /> 
  </wsdl:input>
- <wsdl:output>
  <mime:mimeXml part="Body" /> 
  </wsdl:output>
  </wsdl:operation>
- <wsdl:operation name="GetCitiesByCountry">
  <http:operation location="/GetCitiesByCountry" /> 
- <wsdl:input>
  <http:urlEncoded /> 
  </wsdl:input>
- <wsdl:output>
  <mime:mimeXml part="Body" /> 
  </wsdl:output>
  </wsdl:operation>
  </wsdl:binding>
- <wsdl:binding name="GlobalWeatherHttpPost" type="tns:GlobalWeatherHttpPost">
  <http:binding verb="POST" /> 
- <wsdl:operation name="GetWeather">
  <http:operation location="/GetWeather" /> 
- <wsdl:input>
  <mime:content type="application/x-www-form-urlencoded" /> 
  </wsdl:input>
- <wsdl:output>
  <mime:mimeXml part="Body" /> 
  </wsdl:output>
  </wsdl:operation>
- <wsdl:operation name="GetCitiesByCountry">
  <http:operation location="/GetCitiesByCountry" /> 
- <wsdl:input>
  <mime:content type="application/x-www-form-urlencoded" /> 
  </wsdl:input>
- <wsdl:output>
  <mime:mimeXml part="Body" /> 
  </wsdl:output>
  </wsdl:operation>
  </wsdl:binding>
- <wsdl:service name="GlobalWeather">
- <wsdl:port name="GlobalWeatherSoap" binding="tns:GlobalWeatherSoap">
  <soap:address location="https://www.webservicex.net/globalweather.asmx" /> 
  </wsdl:port>
- <wsdl:port name="GlobalWeatherSoap12" binding="tns:GlobalWeatherSoap12">
  <soap12:address location="https://www.webservicex.net/globalweather.asmx" /> 
  </wsdl:port>
- <wsdl:port name="GlobalWeatherHttpGet" binding="tns:GlobalWeatherHttpGet">
  <http:address location="https://www.webservicex.net/globalweather.asmx" /> 
  </wsdl:port>
- <wsdl:port name="GlobalWeatherHttpPost" binding="tns:GlobalWeatherHttpPost">
  <http:address location="https://www.webservicex.net/globalweather.asmx" /> 
  </wsdl:port>
  </wsdl:service>
  </wsdl:definitions>

Working with XML in integration scenarios is always a tedious task due to the quite complex services and message formats available on the market today, including their associated WSDL files describing them. It becomes especially complicated if different namespaces are used in the WSDL files. Namespaces need not only be considered during the definition of web services, but they also play an important role for many configuration exercises in SAP HCI, for example when:

• Defining the concrete service you want to invoke from a list of available services within a WSDL document
• Using an XPath expression to address content within an XML message that defines the routing behavior within a Content-Based Router
• Accessing fields in an XML document for storing them in the message’s header or the exchange’s properties area using the Content Modifier
• Filtering parts of an XML message using the Content Filter

In all the above-mentioned cases you need to somehow address certain fields in the message’s XML payload. If the payload contains fields originating from XML sources with different namespace declarations in their associated WSDL files, the engine cannot find the required information due to the lack of a proper namespace assignment. Let’s take an example to showcase the problem. Figure 8 depicts an XML document supporting two namespaces.

Figure 8

XML document supporting two namespaces

One namespace (xmlns:customer="https://sap.com/demo/customer") marks tags belonging to a customer definition whereas a second namespace (xmlns:product="https://sap.com/demo/product") is responsible for tags addressing a product.

Because of the introduction of the two namespaces, you can clearly identify which field belongs to the customer and which field belongs to a product. The identifier following the xmlns:-string within the order-tag is called a prefix, which is added to the tags to make them unique. In my example two prefixes are defined: customer and product. Because of the prefix definitions it is possible to have the same tag name belonging to different namespaces. Take a look at the number or name elements shown in Figure 8. There are two: one with the prefix customer, the other with the prefix product. Because of the additional prefixes, you can unambiguously identify which one of the tags belongs to the customer’s name and which one belongs to the product’s name, because the prefixes point to their respective namespace definitions within the order tag.

Equipped with this knowledge about namespace definitions and prefixes you now can dive into the details of the integration flow’s configuration. Continue with the Content Modifier settings (jump back to Figure 1 for your reference). It sets the request message that will be sent by the Request-Reply step to the external web service. For this you have to set the body part of Camel’s message model with the respective XML request message. (For details about Camel’s message model refer to the first part of this article series about SAP HCI, titled “Your First SAP HCI Integration Flow.” The XML request message (file GlobalWeatherCall.xml) is shown in Figure 9.   

Figure 9

An example XML message that is sent to the external web service

Obviously you want to get details about the weather in San Francisco. I simply retrieved this information about the message’s structure from the service’s homepage.

Let’s continue with the definition of the SOAP connection.

Figure10

Configuration of the SOAP-adapter (General tab)

Figure 11

Configuration of the SOAP-adapter (Adapter Specific tab)

In the General tab of the adapter’s configuration screen (Figure 10) you just have to select the Adapter Type (SOAP) and the Message Protocol, which is SOAP 1.x. More interesting are the settings on the Adapter Specific page (Figure 11). Several typical web-service-related fields need to be provided. Almost all of them can be easily retrieved from the web service’s WSDL file. Let’s walk through them one by one:

• Address: This field refers to the web service’s web address. In the respective WSDL file find a tag named <soap:address>. The attribute named location points to the address in which you are interested (Figure 12).

Figure 12

Identifying the web service’s basic information for configuring the SOAP adapter

• Proxy Type: this is to define if you are connecting to a cloud system (Internet) or to an on premise system via the SAP Cloud Connector (on-premise). As we are connecting to a cloud-based SOAP service, we leave the field untouched on the Internet entry.

• URL to WSDL: When selecting this field, you are able to click a Select button to navigate to the WSDL file of your service. That’s all you have to do here: Navigate to the WSDL file and upload it. The entry in the field then is set automatically.
• Service: Each WSDL file can contain several services. You have to tell the adapter which one of the offered services is the one to be invoked. As you can see from Figure 12, the service’s name is part of the very first tag in the screenprint. The information required to fill the Service field is the name-attribute of the service tag.
• Endpoint: As there can be several access points to a service representing different protocols, you again have to specify the concrete endpoint to be taken during run time. Figure 12 helps one more time. You can identify several bindings, but the only one you are interested in is the GlobalWeatherSoap binding. Hence, add this in the Endpoint field.
• Operation Name: As an endpoint can host several operations, the adapter requires the one and only operation it should invoke. For this you have to dig deeper into the WSDL file and find the available operations for a binding. The respective code snippet in the WSDL file is shown in Figure 13.

Figure 13

Identifying the web service's operations

The figure lists the operations for the chosen binding (<wsdl:binding>-tag). From Figure 13 you can derive two supported operations identified by the <wsdl:operation>-tags: GetWeather and GetCitiesByCountry. As you want to retrieve the weather for a certain city, GetWeather is the obvious choice. Add the value into the Operation Name field (Figure 11).

This concludes the configuration of the SOAP adapter. However, one important piece of information is still missing. If you take a closer look at Figure 11 you will recognize the prefix p1: in front of every WSDL-related entry (e.g., Service, Endpoint, or Operation Name). This should remind you of the discussion regarding prefixes. They are needed to clearly identify the respective entries in the WSDL.

Imagine you would like to work with several web services, each coming with its own WSDL file and, therefore, with identically named tags as you have worked with in my example (e.g., the service, binding, and operation tags). So you must work with prefixes to unambiguously distinguish them from each other. However, how do you know which namespace to refer to with the prefix you want to define? Well, this is hidden in the very first tag of the WSDL-file, the <wsdl:definitions>-tag shown in Figure 14.

Figure 14

Details of the wsdl:definitions-tag

Take a closer look at the targetNamespace and the xmlns:tns entries, respectively. They both point to https://www.webserviceX.NET. This is exactly the detail you are looking for to define your own prefix. You just have to inform the integration flow about this prefix so that it can resolve references to entries in the WSDL file accordingly. Interestingly this is not done during the configuration of the Request-Reply step (as you might expect) or as part of the message flow’s configuration.

As potentially several steps in an integration flow require this prefix (I mentioned Content Modifier, Content Filter, and Content-Based Router already), it makes sense to define it on a global level. Therefore, click the modeling canvas somewhere outside of the integration flow’s pool (important: don’t click on any modeled artifact in the environment—only click in the free space around your model). As result you get additional settings in the properties area beneath your model (Figure 15).

Figure 15

Global configuration options for the integration flow

You have to fill the Namespace Mapping field to define the prefix. The entry itself has to follow a certain pattern. It has to start with xmlns: (including the colon), followed by the used prefix, p1 in my example. You can name the prefix however you want using letters, digits, and the underscore, but no separating spaces. After the equal sign (=) the namespace declaration completes the entry. If you need more prefixes due to the use of several web services, separate them using a semicolon.

The combination of the globally defined namespace mapping introducing the prefix and its usage in the SOAP adapter’s configuration makes it possible for the integration engine to retrieve the information needed for handling both the WSDL files as well as the according XML messages unambiguously.

The final step for testing the integration flow is to define the connection to the email server. This has already been explained in one of my previous articles of this series, entitled “Asynchronous Message Handling with SAP HANA Cloud Integration.”

Running the Integration Flow

Now that you have completely configured the integration flow, it’s time to try it out. You should set the Timer Start Event to Run Once for the very first time just to avoid waiting for the timer to expire on the next day at 7:00 am. With the timer set to Run Once, the integration flow starts automatically after deployment—exactly what you need for test purposes. Once it is deployed, connect to your email provider to check the reception of the email. It should look similar to what is shown in Figure 16.

Figure 16

Received email after invocation of the integration flow

Regularly fetching data and forwarding messages to systems are typical requirements for integration solutions such as SAP HCI. I’ve shown you how to prepare integration flows for this purpose. You have seen how to apply the Timer Start Event for triggering the integration flow’s execution on a regular basis. It doesn’t matter whether you want to run the flow only once or in a recurring fashion—the Timer Start Event is prepared for all kinds of invocation scenarios. In addition you have learned in this article how to invoke web services using the SOAP adapter. By defining namespace mappings, the integration engine is enabled to work with several web services in one integration flow at the same time and to distinguish the XML-tags originating from several WSDL-description files unambiguously. This knowledge allows you now to build complex timer- and web-service-based integration scenarios yourself.

Dr. Volker Stiehl

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

 

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

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