1 2 3 Previous Next


32 Posts

Again, SAP is going to surprise you with some new features which have often be requested by you. In this sneak preview, we are going to look at the merging of Business Process Management (BPM), Business Rule Management (BRM) and PI into a single integrated java installation. We will look at how ccBPM can be migrated/replaced by BPM. We will also be using the new Eclipse tool to create objects in the ESR and configure the integration scenarios without using the Swing tools of ESR and ID.

As most of you will have recognized that PI is going toward a java-only installation. During this process, we have made PI easier to develop and configure. We have included BPM and BRM as part of PI to replace the ABAP ccBPM. We are replacing the Swing tools (ESR and ID) with Eclipse for designing interfaces and configuring the integration scenarios. And, yes, we can even use the Eclipse tool to develop Message Mapping.

Come and experience the hands-on sessions of PMC165 and PMC166. Use the new PI Eclipse tools and see how they can lessen the learning curve and provide visual representations of your integration scenarios.

The session description:

  • PMC165 - The combination of the new Java-only deployment option of SAP NetWeaver Process Integration and SAP NetWeaver Business Process Management will allow you to build integration-centric processes. This hands-on session will teach you all the details you need to know to bring your first integration process to life. Model a BPMN-based integration process collecting several messages using the Process Composer, configure SAP NetWeaver PI by using the new integration flows, maintain the connection settings for a reliable message transfer between SAP NetWeaver PI and SAP NetWeaver BPM, and finally run and monitor your solution.


  • PMC166 - SAP NetWeaver Business Rules Management, in combination with SAP NetWeaver Process Integration, opens up new options for integration scenarios. After a brief introduction to the world of business rules, you will implement an integration scenario which benefits from the usage of the SAP business rules engine: a received order message containing several order items is validated against a business rule. In case of violating the rules, you have the chance to correct the message content on the fly and forward it to the target destination via SAP NetWeaver Process Integration.

Hope to see you there!

SAP NW BPM provides modeling, execution and monitoring of business processes that can span multiple systems. It not only orchestrates information between systems, but can also involve users. For example, many companies are using BPM along with MDM during the authorization process before any master data can be entered into MDM.

In the near future, BPM can optionally be installed with SAP NW PI in the same instance, increasing the usability and integration of the two products. BPM is targeted as the eventual replacement for PI’s ccBPM.

In the future, BPM will also be used to provide real-time end-to-end BAM and on-demand (cloud) execution environment.

As we use BPM today and anticipating its usage in the future, whether with MDM, PI, BAM, SAP Business Suites or whatever, we may find that there are some really nice features and also features needing improvements or missing features that can help us.

Through the idea place, we can now provide feedbacks and suggestions that can potential affect the product’s features and directions. You never know, maybe one of our ideas will become part of the product.

The idea place can be accessed at:
Idea Place for BPM

Idea Place for PI

Do you have ideas and feedbacks to improve PI and BPM? Now, you can submit them and solicit opinions from others.

When working with PI and BPM, I am sure we all come across situations where we feel if there are certain features or capabilities in PI and BPM, it will improve our usage of the products. These ideas can be in areas of development, monitoring, administrations, or anything.

Now, there is a place where we can submit our ideas and feedbacks. We can also view and comment on ideas and feedbacks submitted by others...and, even vote for our favorite ones. And, it is possible we can even see our ideas actually to become part of the product.

To submit and view ideas and feedback, you can access the links below:
Idea Place for PI

Idea Place for BPM

With PI 7.30, another IDoc adapter is introduced. This is a java adapter which does not use ABAP services and configuration. In this blog we will examine the configuration requirement for this new java adapter.

Background Info:

With PI 7.30, two new adapters are introduced: Java IDoc and java HTTP adapters. These 2 adapters are useful in the following situations:

  1. To bypass message processing in the ABAP stack, by using the Integrated Configuration of the Advanced Adapter Engine (AAE). This will decrease the resource uilization and increase performance. In another word, we will be able to process more messages faster, with less hardware resources (memory and CPU). In some benchmarks, we have been able to increase the performance of message throughput by 10X.
  2. To be used in the java-only installation of PI 7.30. PI 7.30 provides two installation options: dual-stack (ABAP and java) and single-stack (java-only). By installing the java-only installation, we can decrease the hardware requirement by half, and we can also decrease the installation time by half. Without the ABAP stack, we will no longer have the "classical" IDoc and HTTP adapter in ABAP, therefore, the need for a java adapter.
The new IDoc adapter is "IDoc_AAE".

NOTE: In a dual-stack installation, we can use either the IDoc or IDoc_AAE adapter.


In the blog, we will discuss the recommended configuration. This configuration provides the best logging and tracing capabilities. Also, it allows the sharing of connections for better resource utilization and minimizes configuration errors.

  1. RFC Destination Configuration for receiver communication channels: Just as in ABAP, we have to have an RFC destination. But, in this case, this is a java RFC destination.
    1. Go to NWA and click on: Configuration -> Connectivity -> Destination
    2. Click on "Create":
    3. Enter the required information:
      • Select the local java system as the hosting system.
      • Enter a name for the RFC connection.
      • Select RFC as the destination type.
      • Click on Next.
    4. Enter connection information and click Next: (below is an example)
    5. Enter logon information and click Next:
    6. Enter connection pool settings and click Finish:
    7. Perform a "ping" to test the connection.
  2. RFC Destination Configuration for sender communication channels: When sending IDocs from ERP, an RFC destination to the PI system will be required during the ALE configuration on ERP. In order the create the RFC destination on ERP, a "programid" for an RFC adapter on PI is needed.
    1. In NWA: Configurations -> Infrastructure -> Application Resources
    2. Select the resource adapter, inboundRA:
      1. Enter "inbound" in the filter for Resource Name
      2. Click on the filter
      3. Select Resource Adapter, inboundRA
    3. Configure the default RFC adapter for sender communication channel:
      1. Scroll down to the bottom half of the page
      2. Click on "Properties"
      3. Enter a value for "MaxReaderThreadCount"
      4. Enter "true" for Local
      The ProgramID, XI_IDOC_DEFAULT_PID, must be used when creating the RFC destination on the ERP system.
    4. Create an RFC destination, using SM59, on the ERP syste (not shown here)
  3. IDoc_AAE Adapter Configuration:
    1. Receiver Communication Channel: the receiver is where the RFC destination is needed.
      Below is an example of the IDoc_AAE Receiver Communication Channel.
    2. Sender Communication Channel: (use default configuration)

    Integrated Configuration in the AAE should be used with IDoc_AAE to take advantage of the performance improvments.

At TechEd 2010, there will be an opportunity for you to provide input to the future direction of PI. If you have strong feelings about features, functionalities, and how you would like to use PI in the future, this would be an opportunity for your voice to be heard.

There will be 2 sessions (SS22 and SS23) at TechEd 2010 Las Vegas, each is 2 hours long. The schedules are Wednsday and Thursday, both from 8AM to 10AM.

In these 2 sessions, we will provide a brief overview of the upcoming release of PI 7.3 and give an outlook to the roadmap - how the next generation of SAP NetWeaver PI will evolve. In addition, we are very much interested in your integration needs as input to our future planning for SOA and enterprise service bus. This is a unique opportunity for participants to drive the future of SAP's integration products from governance, development/configuration, runtime, operations and administration perspectives.

To sign up for the session, on the TechEd website, go to the following link:


Participation in the customer feedback and strategy roundtables provides a unique opportunity to influence the direction of the development of SAP software and the SAP NetWeaver technology platform. Through the sessions, you can give SAP greater visibility into your current and emerging business requirements. Customer feedback and strategy sessions bring small groups of SAP customers with expertise in a particular area together with the appropriate SAP product owners. This enables the groups to discuss strategy, business challenges, the product road map, and solution needs. These discussions provide firsthand insight into product enhancements, help you lower implementation risk factors, and strengthen your ties with SAP and fellow customers.

Advance sign-up is required for reserved seating. Each fully paid Full Conference registrant may sign up for a maximum of two customer feedback and strategy roundtables, available on a first-come, first-served basis.

Do you know that PI 7.3 has 2 installation options, dual-stack and java-only single-stack?

Be the first to work on a java-only PI version!

For the PMC262 session, "Using the Advanced Adapter Extended of SAP NetWeaver PI", we will be using the single-stack installation of PI 7.3.  In this session we will cover the java IDoc adapter.  Yes, no ABAP will be used to send IDoc messages between backend SAP systems!  You will be able to learn the configuration requirements for both sender and receiver communication channels in an orders request and response scenario with an ECC backend system.

You will also use the new monitoring tools in NWA to track these messages.

Sign up for PMC262 before all the seats are taken.  This is a hands-on session, there are only a limited number of seats available.

Although, in general, it's not a good idea to bypass authentication when calling a WS service application, it does come in handy sometimes when the application does not really need to authenticate the caller. Some examples might be retrieving non-secure data, e.g. products available for purchase, or airline schedules.

But, when SAP is the provider of such an application, there seems to be no way to get around this requirement; we always have to provide some kind of authentication such as userid and password.

In this blog, we will explore a new feature in ESR 7.1.1 that does allows us to configure such a scenario.

Note: For this blog, you should at least be familiar with the creation of service interfaces in the ESR, generating ABAP proxy with SPROXY, and used SOAMANAGER to create WS services.

What are the steps:

  1. Create the service interface in the ESR, indicating no security.
  2. Generate the ABAP proxy and provide the application code.
  3. Use SOAMANAGER to create the endpoint and binding for the proxy.
  4. Test the WS application.

In this blog, we use a simple request-response example, a "Hello World" application. I will send a request and the response will come back with a text message containing the request message.

Steps in detail:

  1. Create the service interface in the ESR, indicating no security.
    There is a new dropdown, Security Profile. Select No. Everything else in the design process remain the same. Save and activate the service interface.


  2. Use ABAP transaction SPROXY on the service provider system, generate the ABAP proxy and provide the application code.

    Please note, in the configuration tab, the authentication should indicate None. This value cannot be selected, it is carried over from the ESR.

    The application code is quite simple (the response is just saying Hello...):


  3. Use SOAMANAGER to create the endpoint and binding for the proxy. As this is probably not a common task, I will provide a little more details here.
    1. Execute ABAP transaction SOAMANAGER on the service provider system, which will take you to a browser application. Select the tab and click on the link as indicated. image
    2. Create the WS endpoint for the proxy.
      For #2, the external service name can be gotten from the proxy name in SPROXY. It is the same as the service interface name created in the ESR.
    3. A new window will appear. After verifying the entries, click "Apply Settings". You can change the binding name if you wish, as I have done here. The binding name should be unique and be identifiable with the proxy.
    4. Scroll down the browser screen, you will see the following:
      image image
      Unless the "Security Profile" is set to "No" in the ESR, the "No Authentication" option will not be selectable; it will be greyed out.
    5. Select the "No Authentication" option. The "ABAP Service User" entry will appear. This is the user which will be used to logon to the the system, so that no logon information will be needed to be entered by the client or consumer application. image
    6. Scroll up the browser page and save the configuration.
      The service is now ready to be tested.
  4. Test the WS application.
    To test the service, I am using a generic WS/SOAP test program, soapUI, which can be downloaded for free from http://www.soapui.org. I will not go into the details of using soapUI; it should be self-explanatory and the download comes with documentations.
    1. Import the WSDL of the service. The WSDL URL can be obtained from the SOAMANAGER screen:
      In soapUI:
      Copy-n-paste the WSDL URL and click "OK". You will be asked to enter userid and password to access the WSDL metadata.
    2. Expand the soapUI project to see the imported service.
      On the right side is where we can enter the test data.
    3. Enter anything as test data and click "Run":
    4. In soapUI, we normall have to enter runtime authentication information in the propeties section. But, as you can see, the username and password entries are left blank, indicating no authentication is needed.
With NetWeaver Process Integration 7.10, new performance-oriented features have been introduced. We have put together a hands-on session for TechEd 2009 relating to three of these features. Depending on your scenarios, one or more of these features can be used to improve the performance of your interfaces.

This hands-on session will provide three exercises, each relating to a different feature:

  1. Integrated Configuration in the Advanced Adapter Engine (AAE).
    • Message processing without invoking the Integration Engine in ABAP
    • Reduces resource consumption
    • Increases performances up to a factor of 10X
  2. Message Packaging in the Integration Server during Message Processing.
    • Several messages are processed in a single service call
    • No effect on logging and monitoring
    • Increases performance up to a factor of 3X
  3. Direct Connection using webservice runtime in ABAP proxies.
    • Centralized design and configuration of point-to-point connection
    • Reduces resource consumption without going through a middleware
    • Automatic backend configuration

As you upgrade from XI 3.0/PI 7.0 to PI 7.1x, these features can be evaluated to provide additional message throughput and increase the use and life of existing hardware resources.

Session number of this hands-on session will be provided at a later date.

SAP NetWeaver Business Process Management (BPM) involves both people and systems. With the new functionality of BPM in SAP NetWeaver 7.20, this development process becomes much easier.

The Composite Environment (CE) is already the preferred environment to develop user interfaces and interactions. With the new features in BPM, it gives us another option in the coordination and orchestration of messages between systems. As a result, it becomes possible to replace ccBPM in SAP NetWeaver Process Integration (PI) with BPM.

Due to the easiness of connecting to SAP and 3rd party business systems and applications, Processing Integration is still preferred for system integration.

In this hands-on session, we will take a look at how to take advantage of both environments (CE BPM and PI). The session will involve development in both CE and PI. On CE, we will use Visual Composer and BPM. On PI, we will use adapters and message mappings. Web Services will be used for integration between PI and CE.

The diagram below gives a preview of the hands-on session combining people and system integration using CE and PI:


Join us for this exciting new session!

Session number of this hands-on session will be provided at a later date.

We all know about adapter user-module for java adapters, e.g. File, JMS, JDBC, etc.  But, what about for the HTTP adapter, which is an adapter in the ABAP stack?


In this blog, we will take a look at how we can write an user-module for the HTTP adapter.


Obviously, since HTTP adapter is an ABAP adapter, the user-module will have to be in ABAP code.


The concept is as follow.  The HTTP adapter is a service in ABAP, which is named "adapter_plain".  We can examine this service with tx:SICF:



When we examine the details of this service, we see that this service executes the class, CL_HTTP_PLAIN_INBOUND.



Consequently, we can create another service, which also invokes this class.  And, in addition, this service can invoke another class right before it.  This additional class would be our user-module.

So, the steps would be the following:

  1. Create a "Z" class.
  2. Create a new service in SICF.
  3. Add two handlers to the service in the following order:  the "Z" class and CL_HTTP_PLAIN_INBOUND.


Sample HTTP User-Module

For demonstration purpose, in this blog we will create an XML wrapper for the HTTP payload.  The HTTP payload, which is non-XML, can contain any data.  The user-module will wrap the non-XML payload with an XML element.  This way, once in PI, we can use message mapping to decode the content of the payload.


1. Create the "Z" class in ABAP

  1. Enter tx:SE24 to create a class.  I will give it the name: zcl_xml_wrapper



  2. For the interface, enter:  IF_HTTP_EXTENSION


  3. With this interface, a method will automatically be available.


  4. Double-click on the method to enter the code, which will be the user-module.  Below is a sample code to wrap the payload with XML:

    method IF_HTTP_EXTENSION~HANDLE_REQUEST. DATA: wrap TYPE string,       xmlWrap1 TYPE string,       xmlWrap2 TYPE string,       payload TYPE xstring,       xml1 TYPE xstring,       xml2 TYPE xstring,       new_payload TYPE xstring,       util TYPE REF TO cl_xms_part_util.       if_http_extension~flow_rc = if_http_extension=>co_flow_ok_others_mand.       payload = server->request->get_data( ).         util = cl_xms_part_util=>getinstance( ).         xmlWrap1 = '<?xml version="1.0" encoding="UTF-8" standalone="yes" ?><root><mydata>'.         xmlWrap2 = '</mydata></root>'.         CALL METHOD util->convert_string_to_xstring             EXPORTING *            CHARSET = 'UTF-8'               in      = xmlWrap1             RECEIVING               out     = xml1.         CALL METHOD util->convert_string_to_xstring             EXPORTING *            CHARSET = 'UTF-8'               in      = xmlWrap2             RECEIVING               out     = xml2.         CONCATENATE xml1 payload xml2 INTO new_payload IN BYTE MODE.         server->request->set_data( new_payload ). endmethod.


  5. Save and activate the class.

2. Create a new service in SICF

  1. In tx:SICF, navigate to the "xi" node and right-click to create a new sub-element:


  2. Create a unique name for the service.  In our test case, I use the name:  wrap


  3. Provide a description for the new service and go to the "Handler List" tab.  For the handlers, enter two classes.  The first one is the one we created previously, ZCL_XML_WRAPPER.  The second one is the standard class used by the service "adapter_plain", CL_HTTP_PLAIN_INBOUND.


3. Test the user-module

The user-module can be tested using any HTTP test tool.  The URL must be:

We used a standard test tool that has been featured on SDN in the past.  It does not matter what service, interface or namespace are used.  Even though in XI Monitor errors will occur due to no configuration in the Integration Directory, we are only interested the content of the payload to verify if the user-module was executed.


Using SXMB_MONI, we can examine the payload:



SAP NetWeaver Process Integration is continuously improving its capability to handle high-volume message processing. Message packaging is one of the new features to accomplish this. When handling high-volume asynchronous messages, message packaging can improve performance by combining multiple messages as one package.

Processing multiple messages as one package optimizes overall performance in PI by reducing load times, database processing and context changes between the different pipeline steps. All of these are done without effecting the design, development or monitoring of the messages.

Note: The information provided here is based PI 7.1 SPS4.


PI 7.0 SPS13 or PI 7.1.

To enable packaging in your PI systems, the patch level must be at least PI 7.0 SP12. Otherwise the systems can only process single messages. Non-central Adapter Engines, in particular, must be at this level. If not, you must disable sending of packages to these Adapter Engines.

Runtime Processing and Feature Overview:

As asynchronous messages arrive from a sender, they are stored in a queue. In the past, the qRFC scheduler took a single message from the queue and processed it. The qRFC scheduler is now able to process a set of messages (a package) in one LUW. Depending on the number and size of the messages in the queue, this procedure improves performance considerably.

The performance gain are from:

  • Several Messages being processed in one service call.
  • Pipeline program context is loaded once and several messages are processed within that context.
  • Enable mass operations on database, where reads, writes and commits are done on blocks of messages instead of on an individual messages.
In addition, there is no impact on the monitoring and applications level. Messages are still atomic, just the processing is improved. There is no impact on database, error handling, application or even qRFC queues. Therefore, monitoring is also not impacted.

Example Scenario:

We have a continuous flow of messages sent to the Integration Server. Every second a message will arrive. To optimize resources, instead of processing each message individually, we want to package them up into 30 messages per package. In order to do so, we will wait up to 60 seconds for the messages to build up in the queue.

Note: This is just an example, not a recommendation on how a packaging should be configured for such a scenario.

Configuration Steps:

The basic steps are as follow: (I will go into each with more details.)
  1. Enable packaging for the integration server.
  2. Create "Package Configuration Type".
  3. Create "Sender/Receiver Definition".
  4. Create "Specific Package Configuration", using the informaton from the above 2 steps.

1. Enable packaging for the integration server:

Use tx: SXMB_ADM -> Change Configuration (F9), create a new entry:

Category: RUNTIME
Parameters: PACKAGING
Current Value: 1 (for active)


As you can see, the PI 7.1 system I am using, the default setting is "active" or "1". For PI 7.0, the default is "inactive" or "0".

Packaging is turned on by default on all PI 7.1 systems. There is no reason not to use it, since it does not effect the processing or monitoring of messages. It can only improve performance.

2. Create "Package Configuration Type:

Use tx: SXMS_BCM -> New Entries (F5), create a new entry:

Configuration Type: any name (in this example, the name is PACKDEMO)
Description: any text to describe the configuration type
Wait Time: the time in seconds to wait if the queue does not contain the number of messages to be packaged as configured in "Number" (in this example, the wait time is 60 seconds)
Number: the number of messages per package (in this example, we want each package to include a maximum of 30 messages)
Maximum Package Size: the maximum size of the package (in this example, we do not want the package size to exceed 2MB)


With the above configuration the packaging process is as follow:

  1. The package will retrieve messages from the queue, up to 30 messages. But, if there are less than 30 messages, then a timeout of 60 seconds will occur. If there are 30 or more messages, then the package containing 30 messages will be created and processed. Another package will be create to contain the remainder for the messages, at 30 messages per package, until the queue containing less than 30 has been packaged, at which point, it will go into timeout.
  2. If a timeout occurred and expired, the package containing however number of messages will be processed. Another package will be created from the messages in the queue, based on the rule in the previous step.
  3. During the creation of the package, if the max package size is reach, the package will be released and processed, even if the number of messages/package has not been reached.

If you notice the DEFAULT configuration type in the above screeshot, the "Wait Time" is set to "0" or none. This means that messages will be collected into a package from the queue, up to 100 messages, and will be released immediately with no timeout, even if the 100 messages/package has not been reached.

3. Create "Sender/Receiver Definition:

We will now select the messages for a specific interface which we want to package. In this example we want to package messages based on sender information.

Use tx: SXMSIF -> New Entries (F5), create a new entry:

Sender/Receiver ID: any name (in this example, the name is PACKAGE_DEMO)
Description: any text
Service: Business Service used in the Integration Directory's Receiver Determination (in this example, the business service is BLService)
Interface Name: Interface Name used in Receiver Determination (in this example, the interface name is TestValidSource_Async_OUT)
Interface Namespace: Interface Namespace used in the Receiver Determination (in this example, the interface namespace is http://test.com)


4. Create "Specific Package Configuration"

Now, we will put the information from the above 2 configurations into a packaging scenario: which sender and sender interface will be effected; and, how will the messages be packaged and processed.




  1. Highlight the row "Inbound Processing from ..."
  2. Double-click on "Specific Package Configuration"

In the subsequent screen, click to "Change" mode:


Next, click on "New Entries" or F5:


Using the the drop-down selection, populate the values for "Possible Application", "Sender/Receiver ID", and "Configuration Type":


Finally, save the configuration. You will be requested for a transport change list.


A file sender adapter is used for sending the messages. In the communication channel, the polling period is set to 1 second.

When the file sender communication channel is activated, we will see the following in tx: SXI_MONITOR:


As you can see, for the 1st minute, all the messages are waiting to be processed. After 60 seconds, the packages will be created and processed. There is no change to the monitoring of each of the individual messages in SXI_MONITOR.

Package Monitoring

To monitor message packaging, we must turn it on first, using tx: XMSPKSTATCNF


  1. Click on "Switch On".
  2. Click on the green check button to enter it.

Then, bring up the monitor by using tx: XMSPKSTATMON


When executed, we get the following screen:


Double-click on the row for more detailed view:


Also, click on "Display Events (F6)" for more packaging information:


Packaging Info:


In Summary, using Message Packaging:

  • Increases throughput for asynchronous messages on the Integration Server.
  • Packaging is switched on globally, but can also be configured based on specific scenario.
  • Packaging monitors are available.
  • No changes in monitoring, error handling, and development.


CopyXML is a new feature in the Message Mapping tool of PI 7.1. This feature can be used when we wish to copy an XML subtree from the source to target, exactly as is. Why is this so special? Well, by using this tool, we do not need to define the target elements and only one elemet-to-element mapping is required, no matther how many elements are in the subtree.

In this blog, I will discuss on how to use this feature and when the feature will not work or cannot be used.

Using CopyXML:

Let's take a look at the following mapping requirement:

We have a simple customer order document. The source has an address; the target has a billing address and a delivery address. We want to copy all the elements in "address" of the source to "BillingAddress" and "DeliveryAddress" of the target.


As you will notice, the target does not have all the elements defined.

Assign the Mappings:

  1. Double-click on "BillingAddress" of the target, and double-click on the "address" of the source, just as in the previous releases when we want to map from 1 element to another.
  2. Drag a direct mapping line between these 2 elements.
  3. Right-click on "address" and select "Return as XML" in the dropdown menu.


  4. Repeat the steps to map "address" to "DeliveryAddress".


Verifying the mapping:

Below is the result of the mapping. All the elements in "address" have been mapped to "BillingAddress" and "DeliveryAddress".


As you can see, the complete subtree of "address" is copied under "BillingAddress" and "DeliveryAddress". And, we did NOT define any of the "address" elements in "BillingAddress" and "DeliveryAddress".

But, what happens when...

As you will notice, under "BillingAddress", there is an element "address":


Now, let us map something to it. It does not matter what, any mapping will do. In this case, we will just map "Street" to it.


Let's us take a look at the result of this mapping.


The "address" subtree was not copied to "BillingAddress". So, when there is any mapping done to any of the sub-element of the target node, that mapping will take priority and void the CopyXML done to that target.


Graphical variable is a new feature in the Message Mapping tool of PI 7.1. Among many of the new features, I think this simple feature will probably be one of the most useful, if not the most used new feature in PI 7.1.

Graphical varaible will replace a lot of previously development effort for global variables. It makes the development process much easier and brings a lot of clarity on when a "global" value will be calculated.

This blog will go into the details on its advantages and usage.

Using Graphical Variable:

Let's take a look at the following mapping requirement:

  1. Assign the source's "record" count value to the "recCount" element of every row in the target.
  2. Concatenate the source's "lastName" and "firstName" to the target's "fullName".


Create 2 graphical variables:

  1. Right-click on the root node (target_MT) and select "Add Variable".


  2. Name the variable "varNoOfRec".


  3. Create another variable, "varFullName", for the target's node "rows", by right-clicking on "rows" and select "Add Variable".


Assign values to the 2 graphical variables:

  1. Double-click on the variable "varNoOfRec" and assign the following mapping.


    This variable "varNoOfRec" will be executed for each occurence of "target_MT". In this case, it will be executed only once, since "target_MT" is the root.

  2. Double-click on the variable "varFullName" and assign the following mapping.


    This variable "varFullName" will be executed for each occurence of "record" in the target.

NOTE: With where the variable is defined, it is clear as to when it will be executed and can be used.

Use the variables in mapping:

  1. Double-click on "recCount" and drag-n-drop (do not double-click) the variable "varNoOfRec" to the mapping area and assign the following mapping.


  2. Double-click on "fullName" and drag-n-drop (do not double-click) the variable "varFullName" to the mapping area and assign the following mapping.


  3. Assign something to the target's "var2", it is not important what. In this case, I just assigned it the element "data2" from the source. Also, we need to assign "record" to "rows" to complete the mapping.

Verifying the mapping:

Even though the mapping shown here is quite simple, but when there is a complex structure, using variables (especially, when they have to be re-used over-n-over again) can save a lot of development and processing time.

Below is the result of the mapping. The graphical variables are not sent to the target structure. The "recCount" value for each row is only calculate once during the mapping, not for every row. The "fullName", however, is calculated for each row.


A new feature, point-to-point (P2P) connection, is introduced in PI 7.1. P2P connection provides messaging without going through the Integration Engine, but still allows developer to centrally design the interfaces using PI 7.1's Enterprise Service Repository.

By using the Integraiton Directory in PI 7.1, we can also centrally configure the P2P connection for backend SAP systems. The configurations will automatically be distributed or propagated to the backend SAP systems.

Direct Connection is when one system calls another system directly without using the Integration Server as a central instance. Communication takes place using the Web services runtime.

When applications are coupled tightly they can exchange messages directly - without a redirection through a middleware (like the Integration Server) that offers services such as mapping. However, this peer-to-peer message exchange can still be configured (technical address of the Receiver System, authentication, security settings etc) in one central place.


Below provides an introduction to the configuration of Direct Connection.

A detail article of the step-by-step guide is available from:
Point-to-Point Direct Connection Design and Configuration in SAP using NetWeaver Processing Integration 7.1

An offline demo of the design and configuration is also available from:
Demo for Design and Configuration of Direct Connection in SAP NetWeaver PI 7.1

Design and Configuration Steps:

The basic steps required for the complete design and configuration process are as follow:

  1. Design the inbound and outbound interfaces in the Enterprise Service (ES) Repository.
  2. If any of the business systems is an SAP system, then ABAP proxies will have to be generated on the corresponding backend SAP system, using the interfaces in the previous step. The primary reason is that during the activation process in the Integration Directory (ID), the proxy objects of the interfaces will be checked. If the proxies do not exist, then the activation will not be completely successful.
  3. Configure and activate the ID objects, specifically the receiver communication channel and the direct connection.
  4. Test the connection using the ABAP proxies. (Sample proxies and programs are included in the appendix.)

Point-to-point connection allows a much greater message throughput performance, simply because a middleware is not involved in message processing. However, because of this, services such mappings, dynamic receiver determination, ccBPM (as provided by the middleware) are no longer available during the message exchange.

When an environment contains many point-to-point connections, the administration and maintenance of connections becomes quite cumbersome to support. This is where the benefit of SAP Netweaver 7.1 Process Integration (PI) becomes obvious. PI provides a tool and infrastructure to centrally design, configure and support of the point-to-point connection. With PI, message types and interface can be designed in the Enterprise Service (ES) Repository, and connection configurations and communication channels can be done in the Integration Directory (ID).

PCK Configuration in NetWeaver 7.1


Partner Connectivity Kit (PCK), in addition to allow partners and subsidiaries to integrate with PI systems, can also be used to test Java adapters, including adapter user-modules. The configurations to enable PCK in NW 7.1 has changed, mainly due to the unavailability of the J2EE Visual Administrator in NW 7.1. This blog is to provide the updated configuration steps.


To get additional background, benefits and limitations of PCK, please reference the blog: PCK for Enabling & Testing SAP NetWeaver XI Adapter Scenarios

h3. Configurations:
The steps below assumes that you have already installed and deployed PCK in NW 7.1.
  • PCK configuration changes.
Add aii.properties file to the J2EE server. Make the appropriate changes to the aii. properties file. (An example of the file is in the Appendix.) An example of the aii.properties file directory path is: /usr/sap/<sapsid>JC00/j2ee/cluster/server0. The directory for the my sample installation is /usr/sap/A24/JC70/j2ee/cluster/server0. Sample aii.properties file:
  1. Local AII Properties #####
################################ com.sap.aii.ib.client.properties = com.sap.aii.ib.client.,com.sap.aii.ib.core.,com.sap.aii.connect.,com.sap.aii.ib.server.,com.sap.aii.docu.,com.sap.aii.pck.


  1. PCK Connection Parameters
  2. NetWeaver 7.0   simple - robust - model driven


com.sap.aii.connect.directory.contextroot = pck


  1. Replace 'HostName' with the name of your J2EE host
com.sap.aii.connect.directory.name     = CHIN00413560A


  1. Replace '50000' with the httpport of your J2EE host (cf. SAP note 604564)
com.sap.aii.connect.directory.httpport = 57000


  1. Replace '50001' with the https-port of your J2EE host (cf. SAP note 604564)
com.sap.aii.connect.directory.httpsport = 57001


  1. Replace '50004' with the rmiport of your J2EE host (cf. SAP note 604564)
com.sap.aii.connect.directory.rmiport  = 57004


  1. Single Sign On (SSO). Replace 'false' with 'true' to configure SSO (cf. SAP note 810554)
com.sap.aii.ib.core.sso.enabled = false


  1. Client Parameters
  1. Appl name (do not change)
com.sap.aii.ib.client.applicationname.directory = sap.com/com.sap.xi.pck/


  1. Replace 'EN' with the languages of your PCK installation
com.sap.aii.ib.client.login.languages = EN


  1. Server Parameters
  1. Classpath Resolver Service Name (do not change)
com.sap.aii.pck.server.compiler.classpath_resolverServiceName = classpath_resolver
Please pay special attentions to the following parameters, they will probably need to be modified:

  1. com.sap.aii.connect.directory.name
  2. com.sap.aii.connect.directory.httpport
  3. com.sap.aii.connect.directory.httpsport
  4. com.sap.aii.connect.directory.rmiport


Filter Blog

By date:
By tag: