jin.shin

Podcast: How it Works - ABAP Proxy Communication with Advanced Adapter Engine in SAP NetWeaver PI

Jin Shin — Wed, 10 Mar 2010 05:31:02 GMT

In this podcast, we take a closer look at how proxy communication between ABAP backends and the Advanced Adapter Engine works in SAP NetWeaver PI Enhancement Package 1 for release 7.1. Proxy communication is nothing new in Process Integration. However, before 7.1 EHP1 came along, proxy communication was not possible when performing local processing with the Advanced Adapter Engine. So this podcast gets into why enabling such communication is important and, as you might have guessed, how it works.

Podcast: How it Works - End-to-End IDoc Packaging in SAP NetWeaver PI

Jin Shin — Mon, 01 Feb 2010 05:33:23 GMT

The topic for this podcast is End-to-End Idoc Packaging in SAP NetWeaver Process Integration. In this podcast, we take a closer look at the new IDoc package processing capabilities developed for the sender IDoc adapter and delivered in SAP NetWeaver PI Enhancement Package 1 for releases 7.0 and 7.1. We examine the challenge faced in SAP NetWeaver PI before EHP1 and how the new feature now addresses this challenge.

Let's Talk PI... AAE - Advanced Adapter Engine or the "Answer to Accelerated Execution" - You Decide!

Jin Shin — Wed, 30 Sep 2009 08:40:29 GMT

It is not uncommon for customers who have a middleware solution deployed in their landscape to periodically ask "How can we accelerate message processing and improve message throughput in our middleware solution?". For SAP NetWeaver Process Integration customers, the answer is clear: AAE - Advanced Adapter Engine or you might say the "Answer to Accelerated Execution".

Starting with SAP NetWeaver Process Integration 7.1, the Advanced Adapter Engine was introduced where "local" message processing can now take place. Why "local"? Because common mediation services such as routing and mapping are locally provided in the Advanced Adapter Engine. That translates into significant gains in performance and message throughput. As a bonus, the configuration process is much more simplified - with the new Integrated Configuration Object, all configuration is completed in one place. To many this is old news. Yet there are still many customers who are hestitant to take full advantage of AAE.

Let's Talk About It!

At SAP TechEd 2009 come join us at the Expert Networking Lounge (Phoenix, Vienna) where we can take a look "under the hood" of PI and AAE and have an interactive discussion of why you must take advantage of the Advanced Adapter Engine.

SAP PI 7.1 Mapping Enhancements Series: Correct Structural Inconsistencies

Jin Shin — Fri, 15 Feb 2008 14:24:16 GMT

Introduction

Mapping programs can potentially undergo many structural changes during its lifecycle. PI/XI developers know far too well that a structural change can reap havoc on an existing message mapping. This is because for each target mapping defined, there is a corresponding XPath expression that is used by the mapping editor to locate the field in the source and target structure. If a new element name or hierarchy level/node is introduced, the original XPath expression becomes invalid and the mapping editor can no longer locate the correct field to map from/to.

In SAP NetWeaver Processs Integration (PI) 7.1, this problem still exists. HOWEVER, a new enhancement to the mapping tool in PI 7.1 allows for adjustments to the mapping in an interactive way to relieve some of the pain when structural changes are introduced to the mapping. This new function is called Correct Structural Inconsistencies/Reload with Improvements.

Using the "Correct Structural Inconsistencies" Function

Consider an example where the original message mapping looks as shown below:

Both the source and target messages have "flat" structures. Now imagine that a new requirement is introduced for this mapping where a new target message with a more hierarchical structure is required and the name of an element is changed.

In the new structure, elements 'Street', 'City', and 'ZipCode' are subelements under 'Address' and elements 'Phone' and 'E_Mail' are subelements under 'Contact'. Plus notice that 'Name' has changed to 'FirstName'. Let's see what happens when the original target message is replaced with the new one.

As you can see, a familiar processing log pops up listing all the target mappings that had to be deleted and skipped because the path to the original field could no longer be found. However, you probably noticed a new button on the toolbar:

Note that the "Correct Structural Inconsistencies" function appears only if, at the very least, a field used in a target-field mapping cannot be found when a mapping is opened or a new message is introduced.

When selecting the Correct Structural Inconsistencies button, an interactive dialog will appear that gives you an opportunity to reassign the mapping from the original field to a field in the new structure. For example, in the first case, the function evaluates the missing field /ns0:User_0/Name. This should be mapped to 'FirstName' in the new structure. So simply highlight 'FirstName' and select the Move button.

Once moved, the target mapping will immediately indicate that the mapping is complete and the interactive dialog shows the mapping of the old field to the new field. It also moves on to evaluate the next missing field /ns0:User_0/Street.

You proceed with the interactive dialog in this manner until all the missing fields are replaced with a new one or the missing field is skipped. In the end, in our example at least, the interactive dialog completely reassigns all the missing fields and the new mapping is complete. Notice that the Correct Structural Inconsistencies button is no longer visible.

SAP PI 7.1 Mapping Enhancements Series: Graphical Support for JDBC and RFC Lookups

Jin Shin — Fri, 15 Feb 2008 12:08:27 GMT

Introduction

In SAP NetWeaver Process Integration (PI) 7.1, there is now graphical support for JDBC and RFC mapping lookups in message mappings, instead of having to create a user-defined function with the relevant lookup code as in previous releases (e.g. XI 3.0/PI 7.0). This new feature significantly facilitates the creation of such mapping lookups and allows the PI developer to allocate his/her time to other mapping requirements.

Defining JDBC Lookups Graphically

Prerequisites

The JDBC channel to be used for the lookup must be configured and activated in the Integration Directory.
The definition of the table used for the lookup must already be imported into the ES Repository as an external definition (see the SAP PI 7.1 Mapping Enhancements Series: Import SQL Table's Metadata blog within this series by William Li for details).

Procedure

The first step in setting up a JDBC lookup graphically is to create a message mapping parameter within the Signature tab (for more information on parameters, see the related blog in this series SAP PI 7.1 Mapping Enhancements Series: Parameterized Message Mappings). The parameter should be an 'Import' parameter and have Category 'Adapter'and Type 'JDBC'.

Once the parameter is defined, you can proceed with defining the JDBC lookup in the target field mapping within the mapping definition. The JDBC Lookup standard function can be found among the functions in the Conversions category.

After the JDBC Lookup function is inserted into the data-flow editor of the mapping, bring up the properties for the function by selecting 'Properties' from the context menu or simply double-clicking on the function. This is where the SELECT statement can be defined graphically.

Within the properties:

Select the parameter to be used for the lookup. The parameter is maintained within the Signature tab as shown above. The name of the actual communication channel used for the lookup will be the value for this parameter.
Select the relevant external definition that corresponds to the table definition (see prerequisites). Note that, currently, the external definition must be located in the same SWCV as the mapping (of course, usage dependencies can be configured to allow for an external definition located within an external SWCV).
Move all fields to the left that should be used for reading a row in the database table (e.g. corresponds to the where clause in a SELECT statement. Source fields or results values from other functions must provide the input to these fields.
Move all fields to the right that should return a result from the SELECT statement. These results returned to these fields can then be processed further in the mapping.

And there you have it! The JDBC lookup setup is complete.

Defining RFC Lookups Graphically

Prerequisites

The RFC channel to be used for the lookup must be configured and activated in the Integration Directory.
The definition of the RFC structure used for the lookup must already be imported into the ES Repository as an imported archive.

Procedure

In procedure for setting up an RFC lookup graphically is very similar to the procedure for the JDBC lookup:

A message mapping parameter must be created within the Signature tab. It should be an 'Import' parameter and have Category 'Adapter'and Type 'RFC'.

Once the parameter is defined, you can proceed with defining the RFC lookup in the target field mapping within the mapping definition. The RFC Lookup standard function can be found among the functions in the Conversions category.

As one might suspect, the key differences reside in setting the properties for the RFC Lookup function itself.

Select the parameter to be used for the lookup. The parameter is maintained within the Signature tab as shown above. The name of the actual communication channel used for the lookup will be the value for this parameter.
Select the relevant RFC function module that will be used for the lookup. Only RFCs already imported as an Imported Object will be listed.
The left column represents the RFC Request message. All fields to be used as input for the request should be selected (double-click). The fields selected for the request will be displayed in the bottom left box.
The right column represents the RFC Response message. All fields to be used capture the response and further applied in the mapping should be selected (double-click). The fields selected for the response will be displayed in the bottom right box.

Now the RFC lookup setup is complete.

Testing

Testing Locally

When testing a message mapping (or operation mappinp) that contains parameters locally, there is a new Parameters tab that must be completed in order to execute the test.

Testing at Runtime

Runtime execution of parameterized mappings requires values to be set at configuration time in the Integration Directory using an interface determination (see the related blog in this series SAP PI 7.1 Mapping Enhancements Series: Parameterized Message Mappings). For JDBC and RFC lookups, the actual channel to be used for the lookup must be configured in the interface determination.

SAP PI 7.1 Mapping Enhancements Series: Parameterized Message Mappings

Jin Shin — Thu, 14 Feb 2008 15:02:04 GMT

Introduction

In SAP NetWeaver Process Integration (PI) 7.1, there is support for using parameters in mapping programs. In general, the ability to pass parameters to/from mapping programs gives them more flexibility and applicability by allowing for the transfer of values at configuration time (e.g. Integration Directory). This is similar to the concept of using parameters for a program method or procedure. Currently, parameterized mappings are supported for:

Message Mappings
Java Mappings
XSLT Mappings

General Properties

Bindings

Since at runtime time, all PI mappings are accessed via a corresponding operation mapping, parameter bindings must be created in order to connect the mapping program and operation mapping parameters. In addition, the actual parameter values can be set at configuration time within the interface determine of the Integration Directory or by using a transformation step in an integration process or monitoring process.

Import/Export Parameters

Import Parameters - transfer values to mapping

Standard functions only allow for import parameters
Values can be passed from both interface determinations and transformation steps

Export Parameters - transfer values from mapping

Values can only be assigned to export parameters in user-defined functions
Values can only be passed using a transformation step and thus, can only be evaluated within integration processes or monitoring processes

Parameter Category

Simple Type - parameters in this category are used to transfer simple typed constants (i.e. xsd:string or xsd:integer) that can be used as import or export parameters.
Adapter - parameters in this category are used to transfer the channel name that is to be used for mapping lookups. An adapter type (e.g. JDBC, RFC) must in addition be selected.

Using Parameters in Message Mappings

In order to use parameters in message mappings, parameters first have to be defined within the signature tab of the message mapping.

Parameters of message mappings can be passed between both standard functions and user-defined functions. Above there are three parameters defined, two of type import and one of type export. Using the parameter ‘dateDelimiter’ as an example, we can, for example, pass this parameter to the standard function concat as shown below.

This is done by opening the properties of the concat function and then selecting ‘dateDelimiter’ as the parameter to be used for the function. The parameter will only be listed if it has already been defined as a parameter in the Signature tab.

Operation Mapping Parameters and Bindings

The message mapping parameters must be binded to operation mapping parameters as shown below.

Setting Parameter Values in Interface Determination

In the Integration Directory, the values can be set at configuration time in the interface etermination object. Once the operation mapping is specified, parameters defined for the operation mapping will be shown at the bottom of the interface determination screen as shown below.

Setting Parameter Values in Transformation Step of an Integration Process

Values can also be transferred from/to an integration process via a transformation step.

SAP NetWeaver Process Integration 7.1: Mapping Enhancements Blog Series

Jin Shin — Thu, 14 Feb 2008 09:20:08 GMT

With SAP NetWeaver Process Integration (PI) 7.1, SAP introduces significant new features and enhancements within the graphical mapping tool that greatly facilitates the design/creation of message mappings going forward. In this blog series, William Li and I cover all the major new features and enhancements that are delivered in SAP NetWeaver PI 7.1. This blog serves as the central page from which you can branch into the specific feature or enhancement which is subsequently covered in more detail.

Mapping Enhancements Blogs

SAP PI 7.1 Mapping Enhancements Series: Using Graphical Variable: this blog illustrates how to store partial mappings into a variable for reuse using the new graphical variable feature.
SAP PI 7.1 Mapping Enhancements Series: Share User-Defined Functions: this blog details the use of the new Function Library mapping object.
SAP PI 7.1 Mapping Enhancements Series: Import SQL Table's Metadata: this blog details the procedure for creating an external message from a database table structure.
SAP PI 7.1 Mapping Enhancements Series: Graphical Support for JDBC and RFC Lookups: this blog illustrates how to easily create JDBC and RFC lookups with graphical support (i.e. without any code).
SAP PI 7.1 Mapping Enhancements Series: Parameterized Message Mappings: this blog provides details on the use of parameters in message mappings and required setup.
SAP PI 7.1 Mapping Enhancements Series: Copy XML Subtree: this blog illstrates how to copy an entire XML subtree from source to target.
SAP PI 7.1 Mapping Enhancements Series: Correct Structural Inconsistencies: this blog illustrates a new way of repairing target field Mappings after structure changes are introduced to the mapping.

Demos

This demo illustrates some of the key new features delivered in SAP PI 7.1. The SAP PI 7.1 Mapping Enhancements Series: Mapping Enhancements Demo blog provides more information regarding this demo.
KHNC Webinar Replay on PI 7.1 Mapping Enhancements - if you missed William Li's Know-How Network Conference webinar on February 20, 2008, you can still catch the replay.

General Note

As this blog serves as the main page for this blog series, it will continuously remain updated as new blogs in this area are posted.

SAP Help Portal Documentation

Graphical Variables
Function Libraries
Importing Table Structures from a Database
Graphical Lookup Support: JDBC Lookups, RFC Lookups
Parameterized Mapping Programs
Repairing Target Field Mappings After Structure Changes

SAP PI 7.1 Mapping Enhancements Series: Mapping Enhancements Demo

Jin Shin — Fri, 11 Jan 2008 09:46:45 GMT

This blog serves as an introduction to an online demo that illustrates some of the initial Mapping Enhancements introduced in SAP NetWeaver Process Integration (PI) 7.1. With PI 7.1, SAP introduces significant new enhancements within the graphical mapping tool that will greatly facilitate the design and creation of message mappings going forward. The featured demo illustrates some of those enhancements in PI 7.1 including:

Importing Table Structures from a Database: this is really a prerequisite step needed for leveraging the new Graphical Support for JDBC Lookups feature. With graphical support for JDBC lookups, the requirement to create custom code to support the setup of a mapping lookup is eliminated. Initially in 7.1, graphical support is also available for RFC lookups.

Function Libraries: with this feature, SAP fulfills a highly demanded feature from customers where you can create a library of your own custom functions and reuse them in any message mapping you want - the scope or visibility of the functions will not be limited to a particular mapping as in previous versions.

Parameterized Message Mappings: this feature enables you to pass in parameters to a mapping which might allow you to use one mapping instead of several slightly different versions of a similar mapping to fulfill the minor differences in field value requirements.

Mapping Output of Intermediate Fields to Multiple Target Fields: this feature allows for a subset of a mapping to be reused for multiple target fields instead of needlessly duplicating this common subset for each target field.

General Notes:

There are other new features and enhancements available that are not covered in this demo (e.g. use of graphical variables, correcting structural inconsistencies, and others). However, these mapping topics along with those featured in the demo are covered in the SAP NetWeaver Process Integration 7.1: Mapping Enhancements Blog Series.

Just FYI, for those of you who attended TechEd 2007, and particularly the Mapping Enhancements session, this demo will look familiar to you as it is based on the exercise for the TechEd session.

Also, since ramp-up for SAP NetWeaver PI 7.1 only started in December 2007, most customers (at least as of the publication of this blog) will not have a PI 7.1 version at their disposal. So this demo mainly serves as a preview to most until PI 7.1 becomes generally available to all customers.

SAP NetWeaver Process Integration: Enhanced Receiver Determination for Synchronous Scenarios

Jin Shin — Tue, 11 Dec 2007 14:01:10 GMT

Introduction

Enhanced Receiver Determination was introduced in SPS16 for SAP NetWeaver XI 3.0 (6.40) and SPS07 for SAP NetWeaver PI 7.0 (7.00). This feature basically allows for dynamic receiver determination at runtime. More details on the enhanced receiver determination feature can be found on the SAP Help Portal and also in blog Illustration of Enhanced Receiver Determination - SP16.

Out-of-the-box, this feature can only be implemented for asynchronous scenarios. This limitation is mainly due to a design time check for the Interface Mapping that prevents synchronous and asynchronous interfaces to be matched up within an interface mapping. Since the ReceiverDetermination interface object that is contained in the SAP BASIS software component is delivered as an asynchronous interface, the design time check prevents the use of enhanced receiver determination in synchronous scenarios - i.e. the activation will fail.

Well, there are a couple of workarounds for this:

Circumvent the check
Convert the ReceiverDetermination interface into a synchronous interface

Applying the Workarounds

Circumvent the check

A quick and easy way to allow for synchronous enhanced receiver determination setup is to circumvent the check that prevents a synchronous interface to be matched to an asynchronous interface in an interface mapping. This can be done simply by manually entering the name and namespace of the ReceiverDetermination interface object (e.g. 'ReceiverDetermination' and 'http://sap.com/xi/XI/System' respectively) for the target/receiver interface in the interface mapping, but leaving the value for the Software Component Version empty.

Here's a closer look...

By doing this, the check is bypassed and the interface mapping object can be activated.

Convert the ReceiverDetermination interface into a synchronous interface

If for some reason you don't feel comfortable circumventing the interface mapping check, an alternative option is to convert the ReceiverDetermination interface into a synchronous interface. But since the ReceiverDetermination object is a SAP delivered object within the SAP BASIS software component, we do not want to modify this object directly. Instead, we want to add it into our own software component and modify this instance of the object. This is done by making the SAP BASIS software component a dependent component via the Usage Dependencies feature. More info on setting up Usage Dependencies can found in this The specified item was not found. and on the SAP Help Portal.

Once the usage dependency to the SAP BASIS software component version is set up, navigate to the http://sap.com/xi/XI/System -> Interface Objects -> Message Interfaces -> ReceiverDetermination and open the ReceiverDetermination object. Then switch to edit mode which will launch the following Edit Message Interface dialog:

Select Modify and then change the mode to synchronous. Since a synchronous interface requires an input message as well, you can reuse the Receivers message type used in the output message - it doesn't really matter as long as some message type is used.

The object can be saved and activated at this point. Once saved, the modified version of the ReceiverDetermination object will have a symbol next to it indicated that it has been modified.

Now this modified version can be used in the interface mapping. The remaining items in order to finish the enhanced receiver determination and scenario setup can be completed as normal.

Additional Notes

At this point, one workaround is not necessarily recommended over the other. Both will work as a workaround until SAP PI development comes out with an official solution. I would hazard a guess that the solution might either be a synchronous version of the ReceiverDetermination object being delivered in the SAP BASIS software component version or possibly eliminating the Interface Mapping check when used for enhanced receiver determination or perhaps something else.

Remember that the mapping used for the enhanced receiver determination feature is used for logical routing purposes only. Thus at runtime, the workarounds presented do not have a runtime impact on the actual interfaces used. This is still based on the interfaces set up within the Interface Determination configuration.

Keep in mind that synchronous scenarios do not allow for message splits to multiple receivers. So the enhanced receiver determination mapping must be designed such that, at most, one receiver, is returned. This is the case whether enhanced receiver determination is used or not.

Handling Web Service SOAP Fault Responses in SAP NetWeaver XI

Jin Shin — Mon, 21 May 2007 02:13:56 GMT

h3. Introduction When consuming a web service, its nice when all is working smoothly - the web service receives valid input from the web service client and, in turn, returns a valid response to that client. It would be nice if all services always "worked" in this way or just "worked" period. Well... back to reality. Sometimes bad data is inevitably supplied or changes take place in the implementation of the web service and a SOAP fault response containing application specific error information is sent back to the client. When SAP NetWeaver XI is in the middle, and the receiver SOAP adapter is used to call a web service, technically, XI (specifically the receiver SOAP adapter) is the web service client that initiates the call to a web service and receives its response. XI then passes the response back to the original sender that passed the initial request to XI. In successful cases, this is straightforward. However, in problem cases, the web service will return a SOAP fault message which will either result in a +system error+ message or an +application error+ message in XI, usually with a HTTP 500 response code. In the system error case, there are not many options as far as capturing and handling specifics within the SOAP fault. For application errors, however, the fault payload can be captured/accessed and, if necessary, mapped back to the original senders format. For you seasoned XI experts, none of this is news to you. However, there have recently been some threads on SDN on how to handle these SOAP fault responses, so... In this blog, a closer look is taken at handling SOAP fault application error messages when using SAP NetWeaver XI. It also illustrates how a +fault mapping+ can be used to map a SOAP fault back to a corresponding fault format that the original sender can understand. It also discusses some differences to consider in handling SOAP faults when using the standard soap mode vs. the "nosoap" mode.

h3. SOAP Fault - Application Error Message element within the SOAP Fault message as specified for {code:html}SOAP 1.1{code}. An example within the given link is provided: h3. HTTP Return Codes - soap/nosoap modes h3. RFC to SOAP Example The main example in this blog shows a synchronous RFC to SOAP scenario using a custom RFC client application calling a demo XMethods web service called "Currency Exchange Rate" that returns the currency exchange rate between two countries. There are many threads and blogs on SDN on how to set up a basic RFC to SOAP scenario (just do a SDN search), so this is NOT a "step-by-step". Instead, the focus is on the fault/exception handling aspects of this scenario. h4. About XMethods Currency Exchange Service The "Currency Exchange Service" web service, along with the WSDL (http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl), is provided on the XMethods website at http://www.xmethods.net (http://www.xmethods.net). Its an +RPC style+ service and the basic SOAP request and response (successful case), looks like this:

h5. Request h5. Response The above is an example of a valid request/response case. Now, what if I submitted the request with some invalid input - say +InvalidCountry+ and US for "Country1" and "Country2" respectively as shown:

h5. Invalid Request h5. SOAP Fault - Application Error Response h4. RFC "Stub" Shown below is my remote-enabled RFC "stub" (just parameters, no implementation code) that will, more-or-less, serve as the main client/sender in my RFC to SOAP scenario to send the two "Country" input data to the "Currency Exchange Service" web service. Notice the declaration of the "Exceptions" parameter +CURR_EXCHANGE_APP_ERROR+. The fault payload from the web service will map to this RFC exception. h4. Integration Repository (Design) Below is my imported RFC Z_CURRENCY_EXCHANGE_1. The imported RFC metadata will serve as the sender/outbound/synchronous interface and also contains the relevant request/response/exception message types to be used the corresponding mappings. Displayed is only the RFC Exception message type. For the inbound interface (corresponding to the web service invocation), the Currency Exchange Service WSDL is imported and used for the input and output message types. Based on the fault response payload received while testing the service, a fault message type XML schema (xsd) was created externally and imported as an External Definition, which is what is displayed as "electric-detail" below. Also regarding the import of the WSDL for the Currency Exchange Service, a couple of things to note: ** ** However, even with this option, if the WSDL is imported as is, the namespace for the messages +getRate+ and +getRateResponse+ do not get set to the correct/necessary namespace +urn:xmethods-CurrencyExchange+ as shown above. As a work-around, the WSDL can be tweaked externally and re-imported. Basically, the target namespace reflected in the first line for the definitions element should be adjusted to reflect the namespace "urn:xmethods-CurrencyExchange" and not "http://www.xmethods.net/sd/CurrencyExchangeService.wsdl". The final import should look like this: Regarding the Interface Mapping, a fault mapping must be configured. In order to be able to configure a fault mapping, a Fault Message Type should be specified within both the source and target interface. Then when clicking on the "Read Interfaces" button within the Interface Mapping, a "Fault" tab will appear. Below is a shot of the fault message mapping that maps the Currency Exchange Service fault payload ("electric-detail") to the RFC exception. Note that the "Name" field should reflect the RFC exception name. In this case +CURR_EXCHANGE_APP_ERROR+. h4. Integration Directory (Configuration) As far as configuration is concerned, no special configuration is needed as it relates to fault handling. Standard configuration for the channels (sender RFC/receiver SOAP), receiver determination, etc. should be maintained for this scenario. h4. Runtime - Sample Test Run Using the function module test tool is sufficient in initiating a runtime test scenario for this RFC to SOAP example once the configuration has been complete. Below are some screen shots within the function module test tool and the XI monitoring tool to illustrate what happens at runtime. For comparison, both success and error cases are provided.

h5. Success Case Initiating the request... Monitoring the request and mapped payloads... Monitoring successful response and mapped payloads... Successful response back to original RFC sender... h5. Error Case Bad data will be passed as one of the parameters... An application error will result... A look at the request part and mapped payloads... A look at the application error response fault payload... As you can see, the fault mapping is invoked where the fault payload is mapped back to the RFC exception. Ultimately, the RFC sender receives the application error message as an RFC exception.

SAP NetWeaver XI: Variable Substitution with Adapter-Specific Message Attributes via DynamicConfigurationBean

Jin Shin — Fri, 27 Apr 2007 09:57:04 GMT

Introduction

As many of you already know, Variable Substitution, allows you to dynamically set the target file name scheme or target directory location by substituting a variable placeholder with a value from the XI message payload or XI message header. Adapter-Specific Message Attributes (ASMA, a.k.a. "DynamicConfiguration") are additional message attributes specific to each adapter. For example, the File Adapter has ASMAs like FileName and Directory. Using ASMAs alone, the target directory and/or target file name (more common case) can easily be set to the source directory and/or source file name by setting the appropriate indicators on the sender and receiver channel configuration.

Because such File ASMAs (i.e. FileName and Directory) are available, it would make a lot of sense to be able to use these ASMAs in conjunction with the Variable Substitution feature (e.g. to use the original file name or directory as a prefix or suffix to the target file name scheme or target directory location). Unfortunately, access to the File ASMAs is not accessible by the Variable Substitution feature, even though they exist in the XI message header (within DynamicConfiguration header element). When using Variable Substitution, only certain standard message header attributes can be used/accessed (e.g. sender_party, sender_service, receiver_party, receiver_service, interface_name, interface_namespace, message_id). This is where the DynamicConfigurationBean can be leveraged as a simple workaround. Plus, since the bean is an adapter module, a mapping is not needed to do this. Even if there was a mapping, there wouldn’t be a need to create a field in the target payload to carry the File ASMA so that it can be used in Variable Substitution via the payload option.

Adapter Framework DynamicConfiguration Module

The DynamicConfigurationBean is a standard, SAP-delivered module (e.g. like PayloadSwapBean) that allows you to:

Insert or delete some specific ASMAs

Read some XI message header attributes into ASMAs

Write some ASMAs into XI message header properties

SAP Note 974481 provides more detailed information on the configuration and use of this module, including other example usages.

Using File ASMAs for Variable Substitution

In the following example, the FileName ASMA will be accessed and used for Variable Substitution. Since there are only particular XI message header elements that can be used for Variable Substitution and the DynamicConfigurationBean can read ASMAs and write to many of the common XI message header attributes, we can simply write the FileName ASMA to an inconsequential message header attribute - in this case, we’ll use interface_name. Here are the steps:

In the sender file channel, the relevant ASMA indicators set ...

... and in SXMB_MONI, the File Name ASMA has been populated in the XI message header

In the receiver file channel, the File Name Scheme is set to xi_%fName% as shown below:

Variable Substitution is enabled, with the variable fName matching the variable above in the file name scheme and the Reference set to message:interface_name.

The key to this example is in the following settings. The DynamicConfigurationBean module configuration takes place here. To use the bean, the Module Name has to be set to AF_Modules/DynamicConfigurationBean and should be the first module in the sequence.

Referencing the Module Key (1) for the DynamicConfigurationBean, the following parameters must be set in the Module Configuration section.

As a result, the target file name incorporates the FileName ASMA value.

CAUTION!!!

SAP PI Development strongly advises against modifying XI message attributes such as those accessible for Variable Sustitution (e.g. Sender Party, Sender Service, Receiver Party, Receiver Service, Interface, and Interface Namespace) as unforeseen side effects can potentially occur after such modification. In general, these fields are designed to contain type information only and not data that is specific for a given message (e.g. filename).

One known side effect occurs in scenarios where the sender requests a system acknowledgement. In this case, upon processing of an acknowledgement message by the Integration Engine, additional address records are created in ABAP table SXMSPFADDRESS. So in the context of this blog example, if the sender requests an acknowledgement, a unique filename ends up creating new records in this table when the acknowledgement message is processed.

In order to avoid any unknown consequences and in order to meet the requirement fulfilled by this blog, a mapping that writes the necessary File ASMA into the payload, which can then be used for Variable Substitution would be advised. If no mapping is involved in your scenario, one will need to be created with a field in the target message where the retrieved File ASMA can be set.

Useful Link

For other standard SAP modules, check this XI_Adapter_Notes Wiki page.

TechEd '06, EPI300: Configuring Secure Business-to-Business Integration

Jin Shin — Tue, 08 Aug 2006 21:36:18 GMT

Well, it's that time of the year again - SAP TechEd '06 is just around the corner and the event locations and venues couldn't be better! We're talking Las Vegas, Amsterdam, Bangalore, Tokyo... and what better place than Vegas to kick it all off! Like the other great tracks that will be available at the event, the End-to-End Process Integration Track is geared up and ready to go. We got full coverage of all the major End-to-End Process Integration IT Scenarios including Business Process Management, Enabling Platform Interoperability, Enabling Application-to-Application Processes, and, last but not least, Enabling Business-to-Business Processes, which is where the session I'm going to talk about comes in.

Introduction

Session EPI300 is a combination of B2B and security topics, hence the title "Configuring Secure Business-to-Business Integration". On the coattails of SAP NetWeaver, now in full stride, Process Integration has really hit the mainstream. Just look at the amount of activity and knowledge base on the SDN XI Forum today... Wow! It's come a long way. However, there are some SAP NetWeaver XI topics that haven't quite hit mainstream yet (for whatever reason) and B2B and messaging security seem to be a couple of standouts. Well maybe B2B is just about there, but secure B2B is not a topic that seems to be widely covered in the SDN XI forum and, oddly enough, you can't really implement B2B integration without security.

Session Details

There will be a lot to cover in this session. Here are some session details:

Core Topics

Network and Transport Layer Security (e.g. HTTP and SSL)
Message Level Security (e.g. Digitial Signatures, Encryption, Certificates, WSS)
Authentication and Authorization
Network Topology

Other Miscellaneous

Adapter Specific Security
Access Control Lists
Collaboration Profiles and Agreements
Security specific configuration tasks in ID

We'll also show some cool DEMOs on an actual B2B use case for an industry standard such as CIDX or RosettaNet and, time permitting, a secure web services scenario.

Oh, and we can't forget about the other End-to-End Process Integration track sessions that will be available. SAP NetWeaver Product Manager Paul Medaille has already laid it out for you in his The Process Integration Track at SAP TechEd Las Vegas overview blog. Since this session belongs to the Enabling Business-to-Business Process Integration IT Scenario, I'll be bit biased and list some of the related B2B sessions available below.

HOPE TO SEE YOU THERE!!!

Other B2B Sessions at TechEd '06

PCK for Enabling & Testing SAP NetWeaver XI Adapter Scenarios

Jin Shin — Thu, 09 Mar 2006 12:53:31 GMT

As many of you already know, the main purpose of the PCK (Partner Connectivity Kit) is to enable smaller partners or subsidiaries to integrate their landscape with the primary business partners SAP NetWeaver XI landscape. However, did you also know that it is a great tool and, essentially a development environment, for developing and testing modules (and adapters) and testing adapter features and configuration without the need of an XI system at all? Yes, this is the case and when leveraged properly, it can be an essential asset to enabling your adapter scenarios.

Background

Much like the central and de-central Adapter Engine (AE), the PCK is a J2EE based application with the Adapter Framework as its core. Thus it also includes the adapters that come delivered with the AE (e.g. File, SOAP, JDBC, etc.) and, of course, communicates with XI using the native XI messaging protocol. However, because its intended use is outside the immediate XI landscape, it has its own Integration Builder-like user interface for configuration and, more useful, it can be set up in a loop configuration such that the PCK is both the sender and receiver of a message. This allows for the testing of adapters without having an Integration Server available.

As you can see, the UI has the same look and feel as the Integration Builder Tools.

Loop Configuration

As mentioned, the loop configuration is used when XI is not in the landscape or you simply want to do some local testing without XI. The most essential changes take place in the SAP XI Adapter XI service in the J2EE Visual Administrator tool. The following properties should be changed:

For completing the loop configuration and setting up a test, please refer to the following link: PCK Loop Configuration

Benefits

The primary benefit of using the PCK in such a fashion is the ability to run and test adapter specific scenarios without an Integration Server. Right now, its really the next best thing to having your own portable XI. Not having a dependency to an XI system can provide many advantages in certain circumstances:

Greater flexibility to experiment without putting main XI installation at risk
Local environment (e.g. laptop can test XI scenarios) - can configure and test anywhere, anytime.
Fast way to test and experiment with new adapter features and scenarios
Since this is your own local environment, you have control and can slap on the latest SP without waiting for the latest SP to be applied to the XI system.
Develop, deploy, and test adapter modules, and also the new SAP Conversion Agent.

Limitations

Obviously without an Integration Server in the mix, there are limitations in many respects, only a few of which I'll list:

Not for end-to-end integration testing (e.g. no real receiver determination, routing rules, mapping, etc.)
JPR (Java Proxy Runtime) is not supported. Although the functions of the Adapter Framework are also used by the Partner Connectivity Kit (PCK), the PCK does not support the JPR.
Rather "heavy" environment - full SAP NetWeaver AS Java is a prerequisite for installing the PCK. Memory intensive - recommend having at least 1GB of RAM.

So that there is no misunderstanding, the PCKs main business use is to exchange messages with an Integration Server. However, that is outside the scope of this blog and thus, was not discussed in that regard.

Installation

The SAP Partner Connectivity Kit SR1 installation guide is available on SAP Service Marketplace: PCK Installation Guide - SR1

Multi-Mapping without BPM - Yes, its possible!

Jin Shin — Tue, 07 Feb 2006 02:11:35 GMT

Multi-mapping and BPM (integration process) always use to go hand-in-hand. Since SPS14, this isnt true anymore. In the case of message splits (1:n transformations), multi-mappings can now be created and used in non-BPM scenarios. Referred to in many different ways, but most commonly as mapping-based message splits, this new enhancement affords SAP NetWeaver XI developers an opportunity to take BPM out of the equation for message split based scenarios.

Here are the highlights to get this set up:

Design

In design, create a multi-mapping as if it was being done for a multi-mapping within an integration process transformation. Multi-mapping for a mapping-based message split is created in the same way.

In the Messages tab, you set the cardinality (i.e. occurrence) for the target messages.

Again, for the Interface Mapping, proceed as normal.

Configuration

For mapping-based interface determination, a new option is available starting with SPS14. A radio button option called Type of Interface Determination exists in which option Standard is the default. Choose Enhanced.

Selecting this option changes the Interface Determination screen as shown below. For parameter Interface Mapping, value help is available to select the corresponding Interface Mapping previously set up in design. Mapping-based message split and interface determination is ready to go.

Monitor

In the monitor (SXMB_MONI), notice that after the Request Message Mapping pipeline step, there are multiple SubMainDocuments under Payloads.

Benefits

A mapping-based message split will ultimately produce n individual messages, but not until it reaches the Adapter Engine (AE). Inside the Integration Engine (IE), the messages are grouped together and persisted as one bulk message. The bulk message is sent to the AE where it splits the bulk message into individual messages and persists them. This, along with the absence of the usual overhead included in a integration process, drastically reduces resource consumption and improves performance.

Restrictions

Messages that result from the split in a mapping-based message split are sent using one AE. So only adapters running on the AE are supported. In particular, this means that target IDOC message splits are not supported since the IDOC adapter is not part of the AE.
The target system of the message splits cannot be an integration process.
Attachments from the original message are not appended to the messages resulting from the message split.

jin.shin

Podcast: How it Works - ABAP Proxy Communication with Advanced Adapter Engine in SAP NetWeaver PI

Podcast: How it Works - End-to-End IDoc Packaging in SAP NetWeaver PI

Let's Talk PI... AAE - Advanced Adapter Engine or the "Answer to Accelerated Execution" - You Decide!

Let's Talk About It!

SAP PI 7.1 Mapping Enhancements Series: Correct Structural Inconsistencies

Introduction

Using the "Correct Structural Inconsistencies" Function

SAP PI 7.1 Mapping Enhancements Series: Graphical Support for JDBC and RFC Lookups

Introduction

Defining JDBC Lookups Graphically

Prerequisites

Procedure

Defining RFC Lookups Graphically

Prerequisites

Procedure

Testing

Testing Locally

Testing at Runtime

SAP PI 7.1 Mapping Enhancements Series: Parameterized Message Mappings

Introduction

General Properties

Bindings

Import/Export Parameters

Parameter Category

Using Parameters in Message Mappings

Operation Mapping Parameters and Bindings

Setting Parameter Values in Interface Determination

Setting Parameter Values in Transformation Step of an Integration Process

SAP NetWeaver Process Integration 7.1: Mapping Enhancements Blog Series

Mapping Enhancements Blogs

Demos

General Note

SAP Help Portal Documentation

SAP PI 7.1 Mapping Enhancements Series: Mapping Enhancements Demo

General Notes:

SAP NetWeaver Process Integration: Enhanced Receiver Determination for Synchronous Scenarios

Introduction

Applying the Workarounds

Circumvent the check

Convert the ReceiverDetermination interface into a synchronous interface

Additional Notes

Handling Web Service SOAP Fault Responses in SAP NetWeaver XI

SAP NetWeaver XI: Variable Substitution with Adapter-Specific Message Attributes via DynamicConfigurationBean

Introduction

Adapter Framework DynamicConfiguration Module

Using File ASMAs for Variable Substitution

CAUTION!!!

Useful Link

TechEd '06, EPI300: Configuring Secure Business-to-Business Integration

Introduction

Session Details

Other B2B Sessions at TechEd '06

PCK for Enabling & Testing SAP NetWeaver XI Adapter Scenarios

Background

Loop Configuration

Benefits

Limitations

Installation

Other Useful Links

Multi-Mapping without BPM - Yes, its possible!

Design

Configuration

Monitor

Benefits

Restrictions

Multi-Mapping without BPM - Yes, its possible!