Process Integration (PI) & SOA Middleware

Mapping Errors

Tony Massoglia — Mon, 17 Jun 2013 14:57:02 GMT

Let me preface this post with the comment that most of my documentation is mostly geared towards Basis admins with little PI experience. I try to put together common issues that I see, make general directions on how to resolve that particular type of issue and share with the rest of the people with whom I work. this document is also for a non-production system. In a production environment you would need to be working with your function team before resending an IDoc with WE19.

One of the issues that I have encountered in our environment with custom IDocs is that we get a help desk ticket or issue from our project team saying that the IDocs are not getting to their destination. When you check in sending system everything looks fine (e.g. in WE05 the status is 03 or green light). This means that the IDoc is leaving ECC correctly but somewhere in PI there is an issue.

To start the troubleshooting, in the sending system grab an IDoc number of an IDoc having an issue. Once you have that IDoc number, in your PI system go into IDX5 and search for that IDoc number, in my example below I used IDoc number 487746.

Ensure you change the date range to account for the date of the IDoc.

Next you'll see the correlating XML message of IDoc for which you searched. Double click on that entry to bring up the XML data.

In the XML message you can se the error in the bottom right window.

"Runtime exception occurred during application mapping
com/sap/xi/tf/_MM_ZOTM_TPSDLS01_Stage_Roadnet_Del~;
com.sap.aii.mappingtool.tf7.IllegalInstanceException: Cannot create target
element
/ns0:MT_XMLSQL_Roadnet_Delivery/StatementName/dbTableName/access/G~"

Typically when you see an application mapping error this is caused by someone changing the IDoc structure. With custom IDocs ECC and PI do not update the mappings automatically when the structure is changed. This has caused issues for us numerous times. It's a lot of coordination between your ABAP and PI developers as well as good communication between those teams and the Basis team.

So from here we go back into ECC and run transaction BD64.

Go to the environment menu then generate partner profiles.

Select the PI Model view, in this case QP1CLNT001

Click Execute

Run transaction WE19 and enter the IDoc number for which you previously searched.

Click Execute the click Standard outbound processing on the next screen.

Click the green check box.

Now when you check in your PI system in SXMB_MONI you should see the newly created IDoc has been processed without error.

AUTOCLIENT

amarnath kashinath — Mon, 17 Jun 2013 11:28:40 GMT

Hello All,

In our current project involving Swift integration package, we have to use AUTOCLIENT to integrate our back office applications which in turn will connect to SWIFTnet via Alliance lite 2.

Searched about Autoclient in SCN and other forums but haven't got any concrete information about this. So thought of sharing my stitched thoughts about this which may help some or there is no harm in knowing something new..

Also hoping you have some information about SWIFT integration package or I suggest you can refer my previous blog about SWIFT before going through this. Here is the link for the same. http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/04/05/swift-what-is-it

Starting with what exactly Autoclient is?

AutoClient is an optionally installed part of Alliance Lite2 that you use to integrate software

applications with Alliance Lite2. Through AutoClient, your back-office applications can send and

receive messages and files over SWIFTNet in a fully automated way and with strong security.

This application provides file-based communication to and from FIN and FileAct services. You

can send and receive files containing Standards MT and MX messages and FileAct files.

Few points related to autoclient

1. AutoClient uses a directory structure on the local host to interface with your back-office

application.

2. When you install AutoClient, you must specify a location for the installation directory (by default,

C:\Program Files\SWIFT\Alliance Lite2) and a location for the base directory (by default, C:

\Program Files\SWIFT\Alliance Lite2\files) on the AutoClient host. The base directory contains

four subdirectories: emission, reception, archive, and error

3. The back-office application uses the emission directory to request upload of files by AutoClient

to SWIFTNet. AutoClient regularly scans the emission directory for new files to be uploaded.

The EmissionTimerInMillis polling timer determines how often the emission directory is

Scanned.

4. The back-office application can submit FIN messages, FileAct files, and InterAct messages

5. The emission directory does not require any maintenance because AutoClient automatically

moves a file from its emission directory to its archive directory

when the file has been uploaded to the Alliance Lite2 server.

6. The reception directory contains the files that your organisation receives from counterparties. It

also contains the status of the messages that your organisation sent previously through

AutoClient.

7. AutoClient regularly polls the Alliance Lite2 server for new files that are ready for download.

Files appear in the server when they are completely downloaded and ready for the back-office

application to process.

8. It is the user's responsibility to maintain the reception directory: AutoClient does not

automatically move files from the reception directory. SWIFT recommends that you perform

regular archives of the files in this directory.

9. FIN and FileAct files that have been successfully uploaded to the Alliance Lite2 server are

moved from the emission directory to the archive directory.

10. The error directory contains copies of the files that resulted in an error before or during upload,

together with an error file (with extension .err) containing a description of the error.

11. This section explains the process by which AutoClient handles files to be sent, from the

emission directory up to the Alliance Lite2 server.

Each file must conform to the following basic requirements:

12. the payload file that you want to send to your counterparty, embedded in a FileAct file

transmission

13. a companion parameter file, which contains the SWIFTNet FileAct routing information for the

associated payload file and specifies how the file must be sent

The filename of the companion parameter file is the filename of the payload file with the

extension .fa.

14. The back-office application can also use a default companion file. The default

companion file contains predefined SWIFTNet FileAct routing information. The

AutoClient operator creates the default companion file. There can be only one

default companion file (extension .default) per directory. If the default

companion file is present, it is always used.

The naming convention for the default file is as follows:

– .fa.default

• an LAU file

15. If LAU is required for FileAct files, then the back-office application prepares the LAU data.

The back-office application computes the LAU signature on the payload file, and it adds the

following properties/elements to the companion file:

– Algorithm: HMAC_SHA256

– Value: <computed LAU signature on payload file>

16. Each file must conform to the following basic requirements:

• The file name must have the following characteristics:

– less than 200 characters

– not containing the following invalid characters:

• : (colon)

• ' (single quote)

• \ (back slash)

• The file must be less than or equal to 250 MB in size.

This is just an introductory information about AUTOCLIENT.

In My next Blog, I Will share how exactly we have used this in our application involving swift integration package.

Regards,

Amarnath

Versioning in SAP PI - Part 2, the detail

Robert Warde — Fri, 14 Jun 2013 16:14:16 GMT

I have been tasked with understanding how SAP PI can support different interface versions. Specifically how we will support a SAP system that is being rolled out across the globe.

I recently wrote a short blog entry Versioning in SAP PIabout versioning and had a limited response so I decided the investigate the matter in a little more detail. The following is based upon my own analysis, interaction with other developers, SAP Developer Network, SAP Service Support and external developer resources.

Change Types

Firstly let’s understand the various change types:

Changes that are Backwards Compatible

Addition of new operations
Addition of new data types or modified data types

Changes that are not backwards compatible.

Removing an operation
Renaming an operation
Changing parameters
Changing Structures

There are three known strategies for versioning:

Strict - Any changes result in a new version of the interface. It does not support backwards or forwards compatibility.

Flexible - Any incompatible changes result in a new version of the interface. The interface is designed to support backwards compatibility but not forwards compatibility. This means that any backwards-compatible change is considered safe in that it ends up extending or augmenting a service without affecting the interface.

Loose - Any incompatible change results in a new version of the interface. The interface is designed to support backwards compatibility and forwards compatibility. Instead of accommodating known data requirements, special features are used to make parts of the service intrinsically extensible so that they remain able to support a broad range of future, unknown data exchange requirements. This will result in vague interfaces that place the burden of validation on the underlying service logic. Not a recommended approach.

How do we indicate a new version? Most developers and developer resources suggest using the XML namespace to clearly delineate the version. A namespace value is sent with every SOAP message, HTTP Post or XML document. This allows the system to correctly determine what to do with an incoming message.

Options

With regards to PI the following options were considered

a) Create a new SWCV.

According to SAP documentation ‘a software component version is a shipment unit for design objects in the ES Repository’. You use a SWCV to group together objects that are shipped or installed together.’ SAP uses this approach for the majority of their standard content. You can’t copy objects between releases of a SWCV but use the Transfer Design Objects Function (ESR Menu under tools). This tool will transfer objects only if the source objects are more recent than the target objects or the target objects don’t exist. You can preview the changes and see what will be updated (source version is more recent), what can’t be transferred (the target version is more recent) or what does not need to be transferred (the versions are the same).

b) Create a new namespace with a version number.

Create a new namespace using the same name as the original namespace but adding a version number to the end. This will differentiate the versions although any service consumers will have to reference a different endpoint.

c) Ensure that the interface is backwards compatible.

Ensure all changes to the interfaces are backwards compatible. For example any new fields are optional and coding or mapping changes support both releases.

d) Add a version number to the object names

Add a version number to the object names within the same SWVC and Namespace.

Analysis

a) Create a new SWCV.

Although this is appropriate for deploying different versions of a particular software package it doesn’t allow both versions to be used. Integration Directory objects refer to the interface by Communications Component/Interface Name and Namespace and not the SWCV. The system will not allow you to add two interfaces from separate SWCVs to the same Communications Component Interface Name and Namespace. Therefore this approach will not work.

b) Create a new namespace with a version number.

This approach allows for changes to be implemented without impact to existing interfaces. The current interface would be copied to the new namespace, modified and in the case of an inbound interface the source system would be given the new target. In the case of outbound interfaces the target system would find that the payload would contain a new namespace.

c) Ensure that the interface is backwards compatible.

Backwards compatibility isn’t easy to achieve. The functional requirements evolve over time, planned changes are deferred or cancelled and what seems like a simple change that may not have any impact may change significantly. This may result in having to unpick changes to implement subsequent changes. It also means that interfaces are not being developed correctly. This presents a high risk to existing interfaces and is not a recommended approach.

d) Add a version number to the object names

Although this would work it would be confusing to maintain and is not a clean and elegant solution. I believe this presents a high risk to existing interfaces. It would be very easy to apply a change to the wrong version. This is not a recommended approach.

Proposal

Based upon my analysis I would like to propose option B, using a new namespace for all future development and supporting flexible versioning. At a high level it would work as follows:

Requirements reviewed, assessed
Compatibility
1. Changes not backwards compatible?
  1. Prior version frozen, new release created
  2. Development to use current release
2. Changes backwards compatable
  1. Modify existing version
Development
Deployment
New Version
1. Existing consumers migrate when appropriate.
Updated Version
1. Made available to all consumers on this release.

….repeat

It is very important the process is documented and agreed with the relevant teams. We need to ensure that all parties are aware of the process and buy into it. Supporting documentation, including specifications must be updated so it becomes easy to identify the release they relate to.It is more important than ever that supporting documentation is maintained and completed in a timely manner. Developers working in different geographies need to rely on the documentation they have access to.

A very specific namespace naming convention should be used to make it easy to identify the release that the corresponding objects belong to.

Namespaces should be used to differentiate development work conducted between different projects or areas. The naming conventions that we will therefore adhere to are as follows:

urn:xxxxx.com:PI:<Software Component>:<Region if not in SWC>:<Area>:<Sub-Area>:<Version>

E.g. urn:xxxxx.com:PI:A_B2B_RSP:B2B:CRMPunchout:YYYY

Benefits

No impact on existing interfaces

Ability to support aggressive project timescales

Customers can migrate when they want

Concerns

a) Freezing code, It is not possible to check out OR lock code via a transport. PI has the ability to restrict access to SWCV’s, Namespaces and individual objects via permissions and this is currently used to ensure objects cannot be created or edited in the Q, R and P systems. However, this may become too onerous to maintain but it would work. We have processes in place to ensure that all development requests are managed centrally, are documented and reviewed prior undertaking any work.

b) Migration to new releases. As the other countries play catch-up we will need to support migration to the later releases and then, when appropriate, decommission the earlier releases. How is the catch-up managed? It is annual, bi annual or quarterly?

c) Bug fixing. We must ensure that any bug fixes requested are documented and reviewed to see if they are appropriate. We must ensure that these are bug fixes and not an attempt to slip changes in unannounced.

d) Change Requests. We will need to plan any changes and determine how they will be incorporated into existing developments.

e) Communication. The changes, specifically the new endpoints should be clearly communicated to the project responsible.

Testing

To validate the proposal I performed a test in development. I took a simple HTTP to RFC synchronous interface as an example. Given a material code and language the interface will return the material code and material description from R/3. I tested this before attempting to create a new version.

1 Within the Enterprise Services Repository.

Created a new namespace
Copied ALL objects to the new namespace
Checked the copied objects to ensure that they were copied correctly.
Modify the message mapping to return a different message in the response
Activated the objects

2 Within the Integration Directory (configuration)

Create a new scenario. Same name, adding release as per the namespace.
Update communications component to use new interface
Create new configuration to use new objects
Activate objects

The request will now have a new namespace but everything else is the same. Each interface was tested and both worked as expected.

The test highlighted the following points

Certain objects, such as data types retain the original namespace once copied. A test should be performed with all object types so that post copy actions are documented.
Documentation should indicate what objects in the Integration Directory MAY NOT need to be duplicated. This may include Communications Components, Parties, and Communications Channels etc. There is no reason to duplicate configuration objects that will not be impacted by the change. Although it makes sense to duplicate all the ESR objects certain ID objects will remain the same.

References:

http://www.ibm.com/developerworks/webservices/library/ws-version/

http://soa.dzone.com/news/web-service-contract

http://www.oracle.com/technetwork/articles/web-services-versioning-094384.html

Triggering SLD-registration of PI components

Martin Wendler — Thu, 13 Jun 2013 14:07:01 GMT

Under certain circumstances (e.g. database server move), it might be necessary to re-register the PI components in the SLD. There are several possibilities to trigger this:

Server Restart
Restart of PI Applications
Configuration Wizard

A very simple and direct approach is calling the register method of the RuntimeCheck servlet via the browser:

Integration Repository	http://<pi host>:<pi port>/rep/rtc?op=register
Integration Directory:	http://<pi host>:<pi port>/dir/rtc?op=register
Adapter Framework:	http://<pi host>:<pi port>/AdapterFramework/rtc?op=register
RWB:	http://<pi host>:<pi port>/rwb/rtc?op=register

PI Domain and Integration Server will be created automatically.

For the Integration Server it is necessary to add two associations manually afterwards:

Business System
Application Server Java (Single-Stack) or Application Server ABAP (Double-Stack)

As result all PI components should be available and associated to the same PI Domain.

References

Note 1031321 - Self-Registration of Adapter Engine and RWB fails

Note 764176 - Manual correction of XI content in SLD

Note 1435392 - PI CTC: SLD Configuration after PI AEX initial setup

Open PI Initiative (OPI2) – A view “behind the scenes”

Denny Schreber — Tue, 11 Jun 2013 10:17:33 GMT

Lately I came across the following blog about code sharing and spotted a reference to the OPI2 project. I found the subject of the blog appealing since the motives are quite similar to what let to creation of OPI2. There are often requirements which you cannot solve with the standard means and you have to start to design and develop an extension or own solution to tackle the challenges at work. A lot of material can be found in the SCN or on other websites such as Stack Overflow. However, they usually give good tips to start but are sometimes not mature enough to be used without much tinkering.

With the Open PI Initiative we want to deliver some ready-to-use solutions for special integration needs that are not in the PI standard distribution. I don’t know if all of you are aware of our section in the PI space, but with this blog I wanted to show some of our recent activities.

State of Play

As with most open source projects most of the work is done by the projects core team. A lot of this work is maintenance work such as guaranteeing that the solutions are working with the available SAP NetWeaver PI releases. We are usually testing and enhancing for lots of releases in parallel. Also for the 7.31 AEX Java-only installations we had to enhance the offerings so that they now run perfectly fine on “classic” configuration scenarios on double-stack installations as well as in an Integrated Configuration on a single-stack installation.

We are also building new features into our offerings. The AS2 adapter for example got extended with new features such as Dynamic Configuration of the connection parameters or certificate-based authentication for the Receiver Communication Channel. We are also providing customer-specific versions that are not released in the standard distribution because they are tailored for a very specific purpose.

Nevertheless, we are getting lots of questions regarding the usage of the offerings. Let me answer that question with the following statement: Yes, this software runs in production environments of lots of companies. Furthermore, the contribution part from the community regarding bug finding and solution suggestions works very well. It’s also interesting and surprising which companies use the OPI2 solutions. Since the start of the OPI2 project there have been over 4500 downloads. But usually we get the information about productive users only by chance. Normally, the user contacts us only if there is an issue with the solutions and luckily this is not often the case. Also from our experience we could identify the trend that Scandinavian countries seem to be avid open source users and contributors (or they just like to interact with the project team).

Summary

In the end, one of the main advantages despite the community-based evolution of open source is the learning aspects for all parties involved. This leads to mature and well-tested software. We are encouraging everyone to submit code extension or feature requests, but want to especially highlight that we always welcome new contributors. And last but not least …keep hacking!

Java 7 Webstart with SAP PI Integration Builder tools

Daniel Graversen — Tue, 11 Jun 2013 07:32:55 GMT

I just received the update for Java 7 on a client laptop. I have an idea that update of software is a good thing it keeps the system updated and hopefully have fewer security problems. It seems to be a recurring issue with the Java platform.

I wanted to start my development with SAP PI and the Integration Builder tools. So I was looking forward to see how it would perform. I have seen the Java 7 update on a terminal server on another client. Here there java 7 was unable to start the Enterprise Service Builder or Integration Builder.

On my client laptop I was able to start both tools on the PI 7.31 systems. It did take quite a long time and when they finally started they were using 300mb. In Java 6 they only took up 200mb when they started. If you have 4 windows open then it is the difference in using the swap file or not.

My challenges are that I was not able to start the java 7 version always and it took forever to start, if it did decide to start. So I had to find a way to use the Java 6 WS to run the tools.

The easiest was to use a Windows Shortcut to manage and start the tools. So I created a shortcut for each system and then in the target I had the following information

"C:\Program Files\Java\jdk1.6.0_35\jre\bin\javaws.exe" http://server:54000/rep/start/sso/repository.jnlp

C:\Program Files\Java\jdk1.6.0_35\jre\bin\javaws.exe" http://server:54000/dir/start/sso/directory.jnlp

The javaws needs to be updated to where you are locating your java 6 WS and the server url should be updated to point to your server.

Then I could just copy the shortcuts for PID, PIT and PIP, and just changed the server and port. I now have 6 shortcuts to start the PI tools with. The single sign on does not work, but I can manage to enter my password when starting the Swing tools.

How to send a Test Message from RWB

bhargava krishna talasila — Wed, 05 Jun 2013 09:56:25 GMT

How to send a test message from RWB in PI 7.3 EHP1

Introduction

This document is focused to give a better understanding on testing the interface by sending the message from Run-Time workbench (RWB).As we all know that, we can test the interface by sending test message from RWB. From PI 7.3 the RWB has changed rapidly and it is having many advanced features.Even though this is known to every one, it may helpful for those who recently upgrade to PI 7.3.

In SAP PI 7.3 we have a central tool for overview monitoring the Integration Scenarios in our landscape which is SAP Solution Manger. With these features we can review the information about the processes or Messages.Run-time Workbench (RWB) can be used as a quick test tool for sending the payload directly to integration engine or Adapter engine.

Prerequisites: User should have this role " SAP_XI_RWB_SERV_USER_MAIN "

Step 1: Go to PI Home page and click on configuration and monitoring Home which is available under configuration and monitoring.

Step 2: you will get the below screen. Here you will find the three tabs.

Monitoring 2) Configuration and Administration 3) Testing.

Step 3: Go to testing tab and click on send test message option under testing.

Step 4: you will get the below screen, here we have two options under integration server

Integration engine and Adapter engine.

Step 5: Click on integration engine you will find the below screen

Fill the details like sender component/interface and interface Namespace/ user name and password and quality of service like below.

Step 6: Paste the payload from Message Mapping.

Click on send message.

You will get the pop-up message “Message Sent” like in the above screen.

Step 7: Your message will send to integration engine. You can check the message either in Message monitoring and SXMB_MONI.

You can see the Payload which we sent from RWB in pipeline steps.

Go to inbound/outbound message payload.

It is the same payload which we copied from Message mapping in step 6.

In this way you can send the message from RWB to test the interface.

Regards

Bhargava krishna

Reducing integration effort by leveraging SAP enterprise services part2

Vikas Singh — Tue, 04 Jun 2013 02:25:17 GMT

This is in continuation of the first blog on reducing integration effort by using SAP enterprise services ( http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/06/04/reducing-integration-effort-by-leveraging-sap-enterprise-services )

I'll describe the steps in more detail here.

Step1. Identify services required.

Go to http://esworkplace.sap.com/ and identify the service required. There're various ways you can navigate the content. If you're implementing a new scenario, typically a complete process , you can use integration scenarios ( e.g. agency business ) . Using solution map is higher level ( e.g Sales Order Management ) . Business Scenario Description seems hybrid of the above two and I prefer that. Then, in each bundle you can navigate to the service operation and read through the documentation. Make sure the selected operation is not deprecated. SAP has good documentation around features, configuration required in backend system, error handling and any business function required.

Step2. Identify system set up requirements

Identifying all operations will help to come up with a list of requirements for system set up. It's relatively straight-forward in PI as we just need to import the software component. However, for the back end system, there can be couple of scenarios:

- Service requiring business function activation (e.g. SAP APPL 6.04 requires LOG_ESOA_OPS_2 activation) .

- Service requiring add-ons to be installed by BASIS in SAINT transaction (e.g. ESA ECC-SE 604 requires BASIS to install ECC-SE add on).

Get the ECC activities organised (as mentioned in part1, some of the business functions are irreversible) and import corresponding PI SWCVs into ESR - these could be downloaded from SMP and imported as usual.

Step3. Check components are completely installed in the system.

Go to transaction SPROXY. If the ECC system satisfies all the pre-requisites and PI has the components as well, the SWCVs should appear in transaction SPROXY.

In SLD, the ECC technical system should have the additions appearing as a software component version in Installed software of the ECC technical system.

Step4. Create custom software component version. This is strictly not required but in experience, there's always a need to customize messages and hence it should be created with the required service's SWCVs as the underlying SWCV.

Step5. Test: Once the services are in ECC, you can use them to start doing testing.

Use transaction SPROXY for testing - this should help to identify the elements required in the message to be populated and the business documents processed. In experience, this is where you'll spend the maximum time trying to identify what is required, where to populate the information etc.

You can test using SOAMANAGER as well but I prefer to just use SPROXY and then when the PI configuration is complete use SOAPUI.

Step6. There will be cases where the standard doesn't fit the requirement completely. In that case, perform a data type enhancement in SAP PI in the custom namespace.

This should make the data type enhancement show up in ECC SPROXY. Creating the proxy here will update the ECC structures which are used by backend ECC classes for business document processing.

Step7. Some Hints: As usual, testing can be done by configuration in ID and using SOAP UI. Just couple of hints here:

Many of the standard services are sync and ensure that message logging for sync interfaces is on.

The messages appear in SXMB_MONI in ECC only when there's an error (not application error but more like a system error like configuration, input message not conforming to length / type restrictions etc).

For debugging, you can create a comm channel with your username and turn on HTTP debugging if you're trying to investigate the SOAP message (say headers).

Step 8: Special case: Lean Order being too Lean !

For one of the scenarios, while creating sales order we realised that lean order doesn't have the fields we're interested in. However, there's a good document on SMP about "Enhancement Options for the Lean Order Interface" and it was very helpful

Step 9: Generate some positive karma - Do some good for people maintaining it later. As the development on ECC side is going to involve mostly enhancements, two things can really be useful.

- Keep all the enhancements in a composite enhancement.

- Create a checkpoint group so that it's easier to debug messages.

Step 10: Logging in SAP: For synchronous interfaces, SAP does return the proper messages back to the calling application. However, the functional team doesn't have access / interest to access PI to look at the errors. Hence, we had to build logic to update the messages as an application log (which can be checked in SLG1). This in some ways satisfies their requirement to look at the system to figure out what's going on.

This is one area where perhaps either I'm missing something or SAP needs to provide information so that users / functional consultants can monitor the messages. Many functional consultants don't want to even try to look at XML.

A simple class can be created to log the information and call them at appropriate enhancement points. However, we also created a generic method to convert any exception into a BAPI message.

Code can be referenced here.

https://github.com/viksingh/abaputilities/blob/master/exception_to_message_table

Couple of observations where things could potentially by improved by SAP.

- There should be a free tool by SAP to let users/ functional teams monitor messages during testing. I'm aware of AIF but don't have experience as it's not free.

- Lack of out of box support for JSON RESTful web service in SAP PI. The initial requirement was to use them but then the source application had to be modified to use CXF to generate SOAP web service calls on the calling application side. I was almost ashamed to go back to the third party

Some of the books & articles I found useful.

SAP Press Book: "Developing Enterprise Services for SAP": Although I referenced this book only recently, I found an absolute joy to read and did pick up many things. This definitely helped to refine some of the ideas.

http://www.sap-press.com/products/Developing-Enterprise-Services-for-SAP.html

Enterprise Services Enhancement Guide

http://scn.sap.com/docs/DOC-18402

SOA MADE EASY WITH SAP

http://scn.sap.com/docs/DOC-17416

Blog-Add a field to LORD API

http://scn.sap.com/people/tony.rosenthal/blog/2011/03/18/ecc-lean-order-adding-a-field-to-the-lord-api

Reducing integration effort by leveraging SAP enterprise services part1

Vikas Singh — Tue, 04 Jun 2013 02:10:01 GMT

The motivation of the blog is a conversation I had with couple of friends. They had implemented a new SAP functionality but were hassled by the amount of effort spent in integration. They eventually completed the task but after lots of crazy hours on late nights and sometimes weekends. As both the integration as well as the functional person is a friend and didn't know about using enterprise services, I realised that perhaps not everyone is using enterprise services. Further, I was designing and implementing a solution to integrate SAP ECC with an external application for managing distributors and thought to write this post. Our integration required sending master data from SAP and transactional data updates in SAP ECC in OTC / P2P process area triggered from the external application.

Starting with the basics, look at the definition from SAP from BBA guide.

Enterprise Services: Web services using a common enterprise data model based on process components, business objects, and global data types, and following consistent communication patterns. SAP exposes software functionality as enterprise services.

There's good documentation at http://esworkplace.sap.com/ .

In integration world, I see them as equivalent of classes in application development. If you're able to use pre-existing content, most of the work is already done for you.

Why to go for enterprise services instead of trying to build them from scratch - what are the practical benefits?

- Leverages pre-built solutions reducing in substantial development effort reductions. We were able to reduce development effort to around 60% of initial estimates and even this is high because of the first time efforts in understanding their architecture and doing some prototyping.

- Easy to extend: Any project will require customization not delivered by standard solution and normally making changes later on is very time-consuming. Most of the functionality is already covered and even if additional changes are required - SAP has given a nice framework to customize them first in PI and then carry out adjustments on SAP system in ABAP stack.

- Comes with a lot of bells and whistles: Have error handling, data validation pre-built.

The following points need to be considered though:

- We utilised various software component versions and there were two mechanisms to get them installed in our landscape.

a) Some require installation of an add-on in ECC requiring BASIS effort (e.g. ECC-SE add-on to be installed by BASIS).

b) Others require activation of irreversible business functions (e.g. ESOA_OPS01 for services in SAP APPL). It's important to understand that some of the business functions can't be reversed and hence some amount of regression testing of affected areas need to be performed. SAP provides a test catalogue about the impacted functionality which can help in determining the impact. We tried them first in sandbox. Initially the activation didn't go smoothly resulting in ABAP dumps which go away on activation. However, it's painful as you have to wait for a transaction to dump before activating it. After an OSS message, finally we regenerated all programs of EA-APPL, ECC-SE and SAP_APPL software components.

At a very broad level, there are 5 different activities that need to be done.

i ) Identify which services meet requirements completely ( or to the largest possible extent ). There can be more than one service for a given business function ( e.g SalesOrderERPCreateRequestConfirmation_In_V1 and SalesOrderERPCreateRequestConfirmation_In_V2 for sales order creation ). I noticed two things: The former wasn't able to meet all our requirements and has been deprecated as well. Like any other artefact in software engineering it's best to avoid deprecated services.

ii) PI configuration: This was straight forward in our case as it was simple SOAP to proxy and reverse.

iii) Back end ABAP adjustments: These were made to fill in organizational data as the third party system doesn't have concept of some of the organisational structure, data etc.

iv) BASIS activities: Installation of add-ons (e.g. ECC-SE add on via SAINT), regeneration of affected ABAP programs via SGEN.

v) Co-ordination of regression testing: This may involve change management, regression testing and functional owner of the application / process area.

Some of the points we learnt from experience:

- Be ready to spend time in advance of the actual development in prototyping and investigation. However, it pays back in later stages of projects.

- We had to build application logging on ECC side so that in case of errors a functional person knows what to look for.

- There was one instance where we had to overwrite SAP solution. Fortunately, it can always be over-written as a post-exit method in the implementing ABAP class.

- Update some of the system parameters ( e.g. icm/keep_alive_timeout parameter in downstream PI systems). While transporting ESR contents, we realised that the transport import was failing after 5 minutes. These ESR transports with stnadard SAP content can get really big and it's best to send them in separate transports (for each SWCV) . Our first attempt in trying to import them took 22 minutes in total!

In part2, I'll describe the steps in more detail to make the implementation process clearer but from our experience, SOA is definitely not dead!

Link to part 2 : http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/06/04/reducing-integration-effort-by-leveraging-sap-enterprise-services-part2

How to send message from AAE to IE

justin xie — Fri, 31 May 2013 10:03:05 GMT

Recently, I implemented a interface. The IDOC is already used by ICO which run on AAE. But I need to use receiver plian http adapt, as the AAE_HTTP adapter not support dymanatic config. We cannot change the ICO. First we use the MQ as media. AAE send the message to MQ, then IE pick it from MQ through JMS adapter.

One day a light struck on me, just like an apple atack the Newton.

Why not use http adapter, the http is the PI internal message exchange protocol.

Then the solution become to that AAE send the message through receiver AAE http, IE use the sender http adapter.

Perfect!

This is on PI 7.3.

I show the screenshot below.

1.ICO config, use receiver AAE HTTP to send msg to IE

2. Receiver AAE HTTP Channel

3. configuration scenario

4. Send plain http adapter use in configuration scenario

Working with Images/PDFs in PI using UDF

Ranjeet Singh — Thu, 30 May 2013 06:16:52 GMT

Recently one of our customers asked me about PI capability of handling PDFs. This discussion really got interesting when we started scoping requirement. Just handling PDFs turned out like PI will receive multiple images as base64 encoded string in payload. PI will merge these image file, convert it into PDF and then long list of DOs and Don’ts ultimately send base64 encoded pdf file to 3^rd party application.

My experience with PDF till that point of time was restricted to moving pdf files from one folder to another using AAE so I thought of creating POC first to see what can be achieved through PI.

I started to look out for Ideas at SDN forum and found some of my ex-colleagues (not one ) have implemented some sort of complex PDF handling in PI. Key take away for me here was iText.

iText is a very powerful open source library. Using it’s APIs we can work with PDFs/images in more way than I can count. This library exactly fitted requirement for my poc.

At SDN forum most of the suggestions are to create adapter module or JAVA mapping. Java programming is not best of my traits and I find it easy to work with UDF. Anyway I don’t have to create actual PDF file at source but to send it as base64 encoded string so UDF is best suited for this.

Scope: - PI will receive base64 encoded image as a string in payload. PI will merge these images and create a base64 encoded PDF. PI will put the base64 encoded PDF into a field in target payload which in turn will create xml file at target FTP.

Algorithm: - here I am explaining the basic algorithm.

Read base64 encoded string from payload
For each encode image:
1. Decode the image
2. Convert the image to PDF
3. Add pdf to existing one.
Convert PDF to base64 encoding
Return string to payload.

Implementation:-

For this implementation itext jar “itextpdf-5.4.1.jar” has been used.

Import instructions:-

import com.itextpdf.text.Document;

import com.itextpdf.text.pdf.codec.Base64;

import com.itextpdf.text.*;

import com.itextpdf.text.Image;

import com.itextpdf.text.pdf.PdfWriter;

This is advanced UDF for type queue having one input of type string. I have segregated the UDF code in multiple part for better understanding. I have also included the full version of UDF in last part of blog.

Part 1:Declarations:-

String merge = null; // store base64 encoded merged PDF document
Document pdfDoc = new Document();  //  Constructs a new Document with A4 page size
ByteArrayOutputStream output = new ByteArrayOutputStream(); // store pdf in byte array
PdfWriter writer = null;  // Constructs a PdfWriter
Image img = null;   // Constructs a PdfWriter

Part 2:Processing each encoded node:-

for(int i =0; i<encodedImgStr.length; i++)
{
.
// Code for merging images and creating PDF as described in part 3 and 4
.
}

Part 3:Decode the encoded image and read it into bytes:

String imgStr = encodedImgStr[i];
byte[] imgBytes = Base64.decode(imgStr);

Part 4:Convert images to PDF and merge:-

try{
             // get an instance of an image
                img = Image.getInstance(imgBytes); 
            // get the plain height of the image
               float imgHeight = img.getPlainHeight() + 100;  
              // get the plain height of the image
                 float imgWidth = img.getPlainWidth() + 100;  
              // create the page for the document
               Rectangle pageSize = new Rectangle(imgWidth, imgHeight); 
               // set the page size of the pdf
                 pdfDoc.setPageSize(pageSize);
   /* below code is executed only once. When first image is processed*/
                if(i ==0)
                {
   /*below method gets an instance of PdfWriter “writer”. pdfDoc  is the document that has to be written and output is the OutputStream the writer has to write which in this case is ByteArrayOutputStream. */
                      writer = PdfWriter.getInstance(pdfDoc, output);
                    writer.open();
 pdfDoc.open();
                }

// Below method convert image to PDF. At each loop image is converted to pdf and new page is appended.
pdfDoc.add(img);

       }
 catch (Exception e) {
 }

Part 5:Close Document and Writer:-

// once document is written to output stream close the document and writer
pdfDoc.close();
 writer.close();

Part 6:Convert output stream to byte:

// Create a new byte array pdfBytes and copy valid content of output stream output to pdfBytes.
byte [] pdfBytes = output.toByteArray ();

Part 7:Encode bytes to base64 encoding:-

// encode PDF bytes to base64.
merge = Base64.encodeBytes(pdfBytes);
// Add merged base64 encoded pdf to resultlist.
 result.addValue(merge);

Below is the input message. Field “fileData” contains encoded images. For this POC I am not actually using “FileType”. I am using SOAP UI to test my interface.

I have used the same structure for output as well. Below is the output message.

I have written small code in NWDS using iText library to decode base64 string and create a PDF file.

Sample Code:-

import com.itextpdf.text.pdf.codec.*;

public class decodePDF {

            public static void main(String[] args) {

            // TODO Auto-generated method stub

               String file1 = "C:/Documents and Settings/Desktop/iText/PIencoded.txt";

               String file2 = "C:/Documents and Settings/Desktop/iText/PIadapter encoded2.pdf";

                Base64.decodeFileToFile(file1,file2);

      }

}

Full version of UDF mergeDoc UDF.

String merge = null;

Document pdfDoc = new Document();

ByteArrayOutputStream output = new ByteArrayOutputStream();

PdfWriter writer = null;

Image img = null;


        for(int i =0; i<encodedImgStr.length; i++)

     {
        String imgStr = encodedImgStr[i];

        byte[] imgBytes = Base64.decode(imgStr);

         try{

            img = Image.getInstance(imgBytes);

            float imgHeight = img.getPlainHeight() + 100;  
                  float imgWidth = img.getPlainWidth() + 100;  

                Rectangle pageSize = new Rectangle(imgWidth, imgHeight); 
                pdfDoc.setPageSize(pageSize);

            if(i ==0)

            {

               writer = PdfWriter.getInstance(pdfDoc, output);

               writer.open();

                           pdfDoc.open();

                        }


                        pdfDoc.add(img);

                     }

                  catch (Exception e) {
                }


          }


 pdfDoc.close();


writer.close(); 


byte [] pdfBytes = output.toByteArray ();

merge = Base64.encodeBytes(pdfBytes);

result.addValue(merge);

We can use iText library to achieve functionality like encryption, removing malicious codes, modify metadata etc. I am still exploring it and hope to find many interesting features we can use.

SFTP - Certificate and Troubleshooting - Guide for Seeburger - Adapter

Stefan Hilpp — Wed, 29 May 2013 08:49:48 GMT

Hello,

in recent years, the SFTP-protocol has become an important piece in the B2B area. Therefor Seeburger had already provided an adapter for PI several years ago.

Although there is also an option existing now to use the SAP SFTP-Adapter which is shipped with PI, there is still a large customer base existing for the Seeburger-Adapter.

With this blog, I want to provide you again with a "HowTo" - Guide that has been created based on the experience of Seeburger-Consultants in various projects. It is not complete but covers many different issues that you might encounter with certificates in your SFTP- Setup.

Please be aware: This document does not replace the SFTP-Adapter-Documentation but should be used like an additional FAQ - Reference.

It is not an "official" document but will also be updated with feedback provided in this blog.

The following (temporary) Link allows for viewing and downloading the document (as pdf).

https://mft.seeburger.de/portal-seefx/~public/e32ac89b-d1d6-4719-807e-8b4244c5baf8?download

Let me know if you encounter any difficulties. Looking forward to your feedback.

Configuration of Ariba Network Adapter with Client Certificate in NetWeaver PI -- II Part

Priya Ranjan Saha — Fri, 24 May 2013 20:18:31 GMT

An empty custom key storage view named AN is created as displayed below.

5 To create the keypair, click on the Create button as highlighted below.

6 Add a new key storage entry to the view as follows:

1 In the Entry Name field, enter AribaKeypair. Retain the default values for the remaining fields.

2 Under Subject Properties, enter values as displayed below. Make sure that the common Name field (CN) value highlighted in red circle refers to a fully qualified DNS domain name of a web server.

3 Click Next in step 3.

4. review the information under Subject Properties and click on Finish button.

7 Select the AribaKeypair in the Key Storage View Details and click on Generate CSR Request button.

1 To download the AribaKeypair.pem CSR file, click on Download link as highlighted below.

2 Open the AribaKeypair.pem in a text editor. It appears as follows.

Then the generated CSR must be signed by one of the trusted CAs supported by Ariba Network

List of Trusted Certificate Authorities given below:

When you purchase a sign digital certificate, it must refer to an organization that is

trusted by Ariba Network. The trusted certificate authorities are :

ABAecom

AddTrust

American Express

ANX Network

BelSign

Belgacom

Digital Signature Trust Co.

Equifax

GlobalSign

GoDaddy

Thawte

TrustCenter

VeriSign

Then CSR response, which is the public certificate received from the trusted CA, must be imported into the custom SAP NetWeaver PI Key storage view. Import the CSR response in to the Key storage as follows:

1 Click on Import CSR Response button.

After that same public certificate must also be applied in the AN Buyer account. Configuration details of Ariba Network adapter is attached below.

Configuration of Ariba Network Adapter with Client Certificate in NetWeaver PI

Priya Ranjan Saha — Fri, 24 May 2013 20:02:21 GMT

Overview Of Ariba Network Adapter

Ariba Network provides you with a single point of integration to thousands of suppliers. Similarly, it provides each supplier with a single point of integration to multiple large buying organizations. You use Ariba Network to find suppliers to purchase products or services from and to invite suppliers to form trading relationships. After suppliers accept the invitations, you can send purchase orders to them through Ariba Network.

Suppliers receive the purchase orders and return invoices, etc. Each supplier has an Ariba Network account and can specify how it wants to receive orders and generate order confirmations, ship notices, and invoices, etc.

Ariba provides PI standard delivery content of Data Mappings between Business application and Ariba Network for Purchase Order and Invoice business scenarios.

The Ariba Network Adapter for SAP NetWeaver implements round tripcommunication between your SAP ERP system and Ariba Network. It allows your SAP ERP system to send and receive cXML documents to and from Ariba Network by

mapping data elements between IDoc and cXML.

The Ariba Network Adapter for SAP NetWeaver runs on the SAP NetWeaver Process Integration (PI), and can be thought of as a library for SAP NetWeaver PI. This library includes integration processes and Java libraries that implement the cXML transport protocol and provide a set of facilities for resolving differences between SAP and Ariba Network.

The following graphic illustrates how the Ariba Network Adapter for SAP NetWeaver enables the communication flow between Ariba Network and the SAP ERP system.

In this particular document I am not going to the detail configuration of Ariba Network adapter, instead of that I have provided an overview how to configure Client Certificate in Ariba Network adapter.

1 Login to SAP NetWeaver PI NWA.

2 In NWA ( click on Configuration Management tab and then Security. Click on Certificates and Keys link as highlighted below.

3 Click on Add View button.

4 In the View Name field, enter Ariba, Description field, enter Key Storage for Ariba Network Adapter, and click on Create.

PI adjustments for app and dB server split

Vikas Singh — Thu, 23 May 2013 06:33:08 GMT

Recently, I was involved in a project with the goal of splitting app server and dB to split them on different hosts. If app and dB server are on the same host, there's no confusion as there's only a single host. However, if in case of dB and app server split, dB host should be taken for technical systems.

We got following errors after app/dB split.

- Error with cache notification.

- Adapter engine not found.

- Business system not found on execution of LCR_GET_OWN_BUSINESS_SYSTEM.

We had to do the following steps in the below order to get it working:

Recreate SAP technical systems

a) Delete existing technical systems for SAP systems.

b) Regenerate these technical systems (RZ70).

2.Regenerate PI business system and technical systems of type "Process Integration"

a)Delete all technical systems of type 'Process Integration'.

b) Delete PI business system

c) Execute PI self registration:

In SAP Net Weaver Administrator:

Configuration Management --> Scenarios --> Configuration Wizard : All Configuration Tasks --> PI SLD Self Registration

This step:

i) Regenerates technical systems of type 'Process Integration'

ii) Recreates PI business system. If PI business system is not deleted in 2 b), this step will fail. If you want to use a different name, it should be done after all steps are complete.

3.Restart integration builder / integration repository / RWB and AE.

Net weaver Administrator:

SAP Netweaver Administrator --> Operation

Management --> Systems --> Start&Stop --> Java EE Applications

com.sap.aii.af.app (Adapter Engine)
com.sap.xi.directory (Integration Builder/Configuration)
com.sap.xi.repository (Integration Builder/Design)
com.sap.xi.rwb (Runtime Workbench)

4.Adjust all SAP business systems to use the new technical system. The technical systems should appear as below.

Hopefully it can save someone some time in trying to work these out.