Hi Experts,

We are trying to arhcive files in a sender system using the "Archive files on SFTP sender "option available in SFTP Sender Channel under advanced mode.We are using ASMA to get Filename dynamically .We have given the path also for archiving.

The problem is we are able to archive the files but when only with .txt being appended to orginal filename.

For eg

If we are picking files 123.xml,345.xsl the files are getting archived in archive folder as 123.xml.txt ,345.xsl.txt. We want it as 123.xml ,345.xsl only .

Please suggest how to go ahead with the issue

Thanks

Swathi

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.

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!

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:

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

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:

1. Requirements reviewed, assessed
2. 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
3. Development
4. Deployment
5. New Version
   1. Existing consumers migrate when appropriate.
6. 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.

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

 

2 Within the Integration Directory (configuration)

1. Create a new scenario. Same name, adding release as per the namespace.
2. Update communications component to use new interface
3. Create new configuration to use new objects
4. 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

1. 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.
2. 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

I am writing this blog for PI beginners who often struggle to select service interface while creating Receiver determination.  In Integration Directory we create business component. Sometimes we forget to assign sender and receiver interfaces to this business component. As result we don’t get service interface in the input help while creating new receiver determination.

I had faced this issue for business component and business system.

Business system we have a blog from our mentor

http://scn.sap.com/community/pi-and-soa-middleware/blog/2010/05/13/cant-find-interfaces-in-the-associated-business-system

This blog is for business Component (Business Service)

Below mentioned thread are example of similar issues.

Service Interface is not coming in Receiver Determination

File2file Receiver Determination Problem

i could not found sender side interface in id

let us say we have below outbound and inbound interfaces in ESR.

1.Create receiver determination without assigning interfaces to business component.

We will see what will happen when you don’t assign interface to Business Component.

Create new business Component Name BC_TEST.

Don't assign any interfaces to sender and receiver tab.

Activate BC_TEST.

No interface is assigned.

i. Creating Receiver determination

select BC_TEST as Communication Component.

Click on input help

As we did not assign any outbound interfaces to Business Component we will not get any interface name.

it displays No Suitable Data Found.

Result is same for Category "ANY" also

ii. Testing scenario in Test Configuration

create Receiver Determination,Interface Determination,Sender agreement and Receiver agreement by manually giving interface name and Namespace.

go to Tools--> test Configuration

here again it will not display the interfaces

we have one more option to test scenario if we don't want to enter Communication Component,interface,Namespace

Go to Interface Determination

click on interface Determination and select Test Configuration.

you will get test configuration with all values filled.

we can test our scenario after giving message payload.

2. Create receiver determination with assigning interfaces to business component.

let us add outbound interface to business Component.

double click on the business Component i.e BC_Test

you will see this.

click on Edit button

Go to Sender Tab and click on help button under Name.

it will display list of outbound interfaces from ESR.

search like this if you want to add one or more interfaces.

if you wan to add only one interface and don't want to scroll down to search then you can follow below one.

after giving interface name just click on Refresh button.

we select one interface SI_EMP_Out.

save the changes and activate it.

i. Creating Receiver determination

Now it will display list of interfaces which come under BC_TEST Business Component.

ii. Testing scenario in Test Configuration

after selecting communication Component it will give list of assigned interfaces.

Hope this helps you..

it is bit of copy from Shabarish Vijayakumar's  blog. But i am sure it can help PI beginners.

References:

Receiver Determination

Testing the Configuration

Business Component

There is lots of information relating to eFiling, other EOY functions and the new RTI for HMRC, however this information only covers systems with ABAP stacks or upto PI 7.3.

I have recently implemented my first PI7.31 Java only stack and my first tasks were creating the HMRC interfaces.

The first thing I knew was that as of version 7.31 there is a new HTTP_AAE communication channel so I was aware I needed to make some changes to the standard content (SWCV EFILING GB 1.0)

Once all the HTTP Channels have been changed to HTTP_AAE you can move over to the Integration Directory.

use the menu and import Model from ES Repository

You then have to configure the scenario assigning the Business Systems to the Templates:

Once complete for all channels, you need to add the communication channels

You need to create the communication channel based upon the Template provided in the ESR Content

You then create all channels until green traffic lights show:

You can then save and activate your scenario.

When creating a scenario using the HTTP_AAE adapter, the majority of the steps are the same.

But before you activate the scenario, you need to ensure that you complete the connection details for HMRC:

you are now ready to test some of your scenarios.

I have a message open with OSS relating to this and will create part 2 after successfully correcting this issue.

This is my first blog post, so any comments are greatly received.  These are the steps i have run through to configure the HMRC interfaces using the Advanced Adapter Engine eXtended installation of PI7.31. 

Introduction

Limitation

Concept

User-Defined function

Testing

Traditionally any SAP HR implementation, will involve multiple interfaces. These interfaces are typically with Benefit, Time or Recruitment based systems.  The key business characteristics of such interfaces are

1. Transmission of PII (  personal information, including Social Security Numbers, Salary etc.) data
2. Ability to secure information both at rest and in transit
3. Ability to transmit high volume of data, typically around employee demographics
4. Predominantly file based interfaces

I have been a part of a few such implementations and observe that customers continue to use legacy file transmission processes (mostly FTP scripts etc.) for SAP integration and have not been very keen to use SAP PI.  The major concern was the inability of PI (until recently) to support their strong security needs, along with issues related to high volume data transfers.

In my opinion this leads to the following:

1. A un-managed integration model, which involves multiple FTP programs, causing a maintenance nightmare
2. Lack of central monitoring
3. In ability to support orchestration requirements
4. High effort to implement non-traditional ( non-file based integration) with cutting edge systems supporting cutting edge technologies like Cloud connectors, Rest based servers etc.

With the recent developments on functionality SAP PI can really be a Savior !

The following features can really help meeting the requirements:

• Security in Transmission

With the availability of the B2B Add-on, SAP PI supports an SFTP adapter for SSH based communication.  This is in addition to SSL based FTPS communication which is available with the  vanilla FTP adapter.   These protocols support the requirements for security in transmission. To add, there is no additional cost associated with the SFTP adapter.

• Security at Rest

Along with security in transmission, there is always a requirement to have encrypted files both within the network and externally. SAP PI supports a PGP module which can be used for the same.

• Re usability - Publish Subscribe Model

HCM customers integrate with multiple vendors for business functions like employee benefits. Most of these vendors require employee demographic information (something like employee master data). SAP PI can be used as a publish-subscribe bus, with ECC generating the data via a generic interface, and PI mapping and transforming it to vendor format

• Cloud Integration/Availability ( Success Factors)

  With the advent of Success Factors which is a new cloud based offering from SAP to support global HR foundation spanning across the recruit to retire cycle along with advanced analytic,  SAP back-end system need to connect to this cloud based offering.  This integration is possible via an on -premise or a on-demand PI solutions.  There is standard SAP content available for this, and the integration is via the SOAP - Axis/SFTP adapters

This is in addition to consolidated Solution Manager based monitoring for PI and the Application systems, including defining of Alert Rules for critical interfaces like Payroll.

Overall this brings in the best practices to integration mechanisms by supporting the development of a consolidated message broker.

The additional cost that might be associated with PI, can be far more lesser than managing an unorganized interfacing architecture.

From past many days I was searching a lots of blogs which can give me real picture of new and advantages of single Java Stack.But dont find any blog which can explain why  SAP is moving aways from its own stack ABAP to Single Java Stack.So,after consulting many SAP consultants and friends I thought to  submarized some of the  top 6 reasons or adavntages why SAP is planning to have single stack only in SAP PI 7.3.I hope it will help those guys who are not from SAP background and planning to join SAP.New SAP features will create  curiousity among Java resources to be part of changing SAP.  

1. When there are 2 stack than messages keep jumping from one stack to another stack.It increases the processing time of the messages(Time taken to process the message completely from ABAP stack to Java Stack.Single stack will increase the performance and throughput will be better.
2. Basis team will thank SAP for moving to single stack as it will help them to install the system fast and also in past restarting both the stack took long time ..now when they have single stack it will help not only to install the system the fast but also system restart will be fast as compare to SAP PI 7.1
3. NO Support for ccBPM.BPM always reduce the performance of system.In SAP PI 7.3 interface will rely on SAP NWBPM(same as ccBPM)but performance will  be high.
4. SAP is also trying to pull the large resource for Java Background who can help them to improve the SAP product and since new SAP PI 7.3 will not support ABAP mapping than people of  Java Background will help them to improve the performance of the system.New SAP PI 7.3 will support Java Mapping not ABAP mapping so it is the right time to pull Java resource to their court before they Go-Live.
5. SAP is also advising customer to limit the usage of ABAP mapping and ccBPM and make most used of Java components.
6. Most important advantages of single stack:-adapters will no longer be stack specific like Idoc adapter is in ABAP stack only.With SAP PI 7.3 Java stack will support all adapters including IDoc adapter.     

Definetly,SAP has taken a bold decision to move away from its own product i.e ABAP to Java,keeping in mind thart coming future is of SAP and inorder to capture the market they need to capture the large Java Resouce who are in market to  support them.    

Hello All,

In my current project we tried to process few interfaces as EOIO and we achieved by enabling it in Communication channel with queue name in version 7.3 single stack.

We had queue name as above it was working fine.

After upgrade of PI from 7.3 to 7.31 all the queues are getting struck in ECC in SMQ2 as below.

Solution:

We have changed the queue name to

XBQA<queue name> high priority

XBQZ< queue name> low priority

Regards

Vijay

In case of Asynchronous Inbound Proxy Interfaces there is often a case where the Interface fails in the ECC system due to issues like Master data not being maintained, incorrect data received from legacy leading to conversion issues eg: Character in Amount or Quantity field, which needs to be continuously monitored through the XML Monitor transaction SXI_MONITOR or SXMB_MONI

SAP has introduced Forward Error Handling (FEH) for Proxy interfaces which also provides the option for sending Email Alerts via the Error and Conflict Handler (ECH) in the Post Processing Office (PPO) Framework whenever the Interface goes into Error. The First part of the Configuration for FEH has been explained in the detailed and informative blog by Michal Krawczyk hence this blog purely deals with the Email alert configuration in ECC.

Below are the detailed steps to be followed to enable this Alert mechanism in ECC -

Disclaimer: Please use Software component and Business process already configured for FEH. Given below is just an example taken for explaining the steps.

EMAIL CONFIGURATION in SPRO

1.     1. The first step in this configuration is to ensure that the standard BADi implementation /SAPPO/ORDER_CR_NOTIFY_DEFAULT of BADi  /SAPPO/ORDER_CREATE_NOTIFIY is active(it is normally active) as can be seen below:

2.    2.  In the Configuration Transaction SPRO, go to Define Worklists and give one of the below names as per your module:

3.     3. Go to Assign Worklist to Business processes and create a record for your respective interface. Please note that this is the same Software Component and Business process created for FEH configuration

4.    4. Go to Process Notifications for Orders in Worklist and create a record as below for your respective Interface

5.    5. After SAVE into customizing request, Choose the record and click on Printworkbench Settings and enter details as below and SAVE:

6.    6. The same priority maintained here needs to be maintained at the Business Process level, which needs to be done in Assign Priority to Business   

          Processes as below:

7.    7. After this, Users need to be maintained in the Worklist defined(ZBP0). This is a one time activity that has to be done in every system(No transport request is created on saving these changes). Transaction code is /SAPPO/WL_CHANGE and execute, you would see your Component along with the Worklist wherein Users can be dragged and dropped as can be seen below:

SAP also provides an option of assigning a complete Organizational Unit in which case all the users assigned to the group would get the Email alert notification. Email would be sent to the Email ID maintained in User settings as below:

8.     8. After this, test your FEH with one failure scenario if an Email is triggered to your ID(your User ID needs to be maintained in the worklist) an Email in the below format should get triggered:

ISSUE WHILE TRIGGERING PPO ALERT EMAIL

On completing the initial Configuration settings for the PPO mail alert, the interfaces were tested to check if they trigger an email to the Users maintained in the above mentioned user list, but there was an issue due to which the EMAIL was not getting triggered:

On contacting SAP it was learnt that there are some settings related to the MAIL functionality that need to be altered. There were two suggestions given by SAP for the same:

Please refer to the following customizing activity:
Cross-Application Components
--General Application Functions
----Print Workbench
------Define Shipping Control

Here the attribute "Storage Mode" is set to value "Print and archive" for Dispatch Control MAIL.

Please remark that the system does not support storage modes "Print and archive" or "Archive only" in this PPO-notification scenario.

As a result PPO orders are generated without triggering a mail notification.

To resolve this issue please choose storage mode "Print only" in the customizing activity mentioned above.

Configuration for the Print Workbench General Setting was done as suggested as can be seen below:

However, this is a general setting for all documents using the print workbench with MAIL.

Alternatively you could adjust the PPO-specific application form /SAPPO/NF_NOTIFICATION_COLL which gets called in your PPO notification scenario via transaction EFRM:

-Choose Tx EFRM

-Enter /SAPPO/NF_NOTIFICATION_COLL

-Choose Change

-Double Click DOCUMENT in the hierarchy shown on the left

-Choose Storage Mode "Print only"

Also Configuration for the Print Workbench PPO Setting in /SAPPO/NF_NOTIFICATION_COLL was done as per alternate method suggested as can be seen below:

Also, the Priority maintained in ‘Print Workbench Settings’ and that assigned at the Business Process level should be the same else there is some standard check that fails resulting in NO mail trigger.

Hi Guys,

I have faced this issue few times in my project.When I was trying to open any of the configuration Scenerio I was getting this below error.I tried searching in SDN but didnt find any suitable answer which can help us to solve this issue.With the help of our Basis team we figured  out why this issue occured and solution to solve this issue.

If you see below when I tried opening receiver determination or receiver agreement of any of the configuration scenerio,I was getting this below error.

Please note it is not specific to any particular configuration scenerio.You will see same error with all the configuration scenerio.  

As the result of this issue,I was not able to make any changes in any of the configuration scenerio(if you want to make any changes in receiver agreement or sender sender agreement or Interface determination etc).Initially we thought that some objects were deleted and causing this problem.

Root Cause:-Service users expired(in some cases it may be locked).

Service users are used for internal communication between XI component. The service users provide dialog-free access to the involved XI components. They have SAP user roles in the ABAP part of the SAP Web Application Server (AS) that are available as user groups in the J2EE part.

For each component, if you see above,service users representing the respective components are created with the appropriate roles in the target components during installation. The passwords of the service users have to be defined during the installation process.

In my case,I was facing this issue with Directory,so I checked this user XIDIRUSER and I was surprised to see that this user was expired.When I changed the password(please use standard password only)and I tried to open the configuration scenerio again,I found that everythings is working now.

So,if you see this kind of issue with SLD,IR or ID,please check the respective service user with the help of basis team and check weather this service user is locked or expired.If expired,reset the password and open it again. 

Regards,

Abhinav Verma

As per thread: SOAP Sender attachment named attachment-1 discussion, SOAP sender Adapter always replaces the incoming attachment names with attachment-1, attachment-2 etc.. And as Stefan Grube mentioned in the thread, this is the default SOAP adapter behavior since it was hardcoded in SOAP adapter for incoming attachments to XI. But most of the times, the business needs the original attachment names at the receiving target application. So, how can we achieve this.

In this blog, I am providing UDF code snippet using which we can retain original attachment names in the mapping by reading incoming attachments using mapping API for attachments (applicable from PI7.1 onwards). Also, with this procedure we can overwrite existing attachments with any content as bytes. Note:- the same can be achieved with a java mapping/XSLT with java enhancements as well.

String attachmentID = null;
java.util.Map map;
AbstractTrace trace;

//gets the input attachment from the source message
GlobalContainer globalContainer = container.getGlobalContainer();
InputAttachments inputAttachments = globalContainer.getInputAttachments();
OutputAttachments outputAttachments = globalContainer.getOutputAttachments();
trace = container.getTrace();
//map = globalContainer.getParameters(); 
try
{
          //checks for the availability of attachments in the input message          if(inputAttachments.areAttachmentsAvailable())          {                    trace.addInfo("Attachments Available");                    //gets the attachmentIds and store it in an Object array                    Collection<String> CollectionIDs = inputAttachments.getAllContentIds(true);                    Object[] arrayObj = CollectionIDs.toArray();                     //Loops at the input attachments to get the content of the attachment                    for(int i =0;i<arrayObj.length;i++)                    {                              attachmentID =(String)arrayObj[i];                              trace.addInfo((i+1) + ") Attachment Name: " + attachmentID);                              Attachment attachment = inputAttachments.getAttachment(attachmentID);                              String contentType = attachment.getContentType();                              byte[] attachmentBytes = attachment.getContent();                              Attachment renameAttachment = outputAttachments.create(attachmentID, contentType, attachmentBytes);                               outputAttachments.setAttachment(renameAttachment);                              //remove each attachment if required. Uncommonent below                              //trace.addInfo("Removing Attachment no: " + (i+1) + " & Name: " + attachmentID);                              //outputAttachments.removeAttachment(attachmentID);                     }          } 
}
catch (Exception e)
{          e.printStackTrace();
}


return           var1;

Attachments sent from SOAP UI as SOAP message to XI.

With the above UDF in the graphical mapping, the results will be as shown below for the inbound/mapping pipeline stages in MONI

Regards,

Praveen Gujjeti

SAP NetWeaver Process Integration (SAP PI) is a component of the Netweaver product group used to facilitate the exchange of information among a company's internal software and systems and those of external parties . Here are some of the errors and its resolution which will definitely be useful.

    1. Cache Update Problems :-

Use transaction SXI_CACHE to update the Integration Directory cache. Alternatively, you can use the following URLs to update the CPA cache. Use XIDIRUSER to refresh the cache.

For complete cache refresh – http://<hostname>:<port>/CPACache/refresh?mode=full

For delta cache refresh – http://<hostname>:<port>/CPACache/refresh?mode=delta

If this does not solve the issue, check transaction SLDCHECK to ensure that connection to SLD is available. If the connection fails, check the configuration in the transaction SLDAPICUST. Make sure that the password maintained is correct and the maintained service user is not locked.

Now in the Integration Repository go to Environment → Clear SLD Data Cache. Also go to Integration Directoy and clear the cache using menu Environment → Clear SLD Data Cache.

Open the XI Start Page and click on Administration. On the Repository tab, choose Cache Overview. Refresh the cache using the buttons/icons on the right. Use XIDIRUSER to refresh the cache. Carry out cache refresh in the same way on the Directory and Runtime tabs.

If you are facing cache update problems in your BPM (say you have modified the BPM, but when executed old version of the BPM is picked up instead of the new one), run the transaction SWF_XI_CUSTOMIZING and press F9 carry out automatic BPM/Workflow Customizing.

    2. Routing Errors :-

• NO_RECEIVER_CASE_BE or NO_RECEIVER_CASE_ASYNC

This means no receiver could be found. Check your Receiver Determination. Activate and update cache. Asysnchronous messages can be manually restarted.

• TOO_MANY_RECEIVERS_CASE_BE

More than one receiver found. Check your ID configuration to ensure that there is exactly one receiver for the synchronous message. Multiple receivers for synchronous interfaces are not permitted.

      3.Mapping Errors :-

• JCO_COMMUNICATION_FAILURE

Check whether RFC destination AI_RUNTIME_JCOSERVER is correctly configured

• NO_MAPPINGPROGRAM_FOUND

Ensure that mapping program exists and is activated. If it exists then update the cache.

• EXCEPTION_DURING_EXECUTE

This error occurs due to erroneous XML formatting. Check your mapping program and ensure that you supply valid input data.

4. Messages stuck in queues

Check the queues using transactions SMQ1 (outbound)/SMQ2 (inbound). Resolve the displayed errors. You can cancel the messages from SXMB_MONI. Execute LUW if necessary and avoid deleting entries manually.

5.Conversion Errors

        Unable to convert the sender service XXXX to an ALE logical system

This error occurs in case of scenarios with IDoc adapters. Whenever you use business systems, make sure that the corresponding logical system name is maintained in the SLD.

Open your business system in the Integration Directory. Switch to Change mode. Access the menu path Service → Adapter Specific Identifiers. Click the button that says ‘Compare with System Landscape Directory’ and chose Apply. Save and activate your change list.

In case of business services, you can manually type a logical system name in the Adapter Specific Identifiers if required. This name should match the corresponding logical system name defined in the partner SAP system’s partner profiles.

4.Errors on the outbound side

Sometimes the link between SAP XI and the target system (say ERP) goes down and messages fail on the outbound side. It may not be possible to restart them from using RWB or the transactions like SXI_MONITOR/SXMB_MONI . In such case generally, messages are picked up and sent via SAP XI when the link returns. However, in some scenarios, it may be possible that SAP XI server could not finish conversation with ERP. Main status of messages is “Processed successfully” – but there is an error in the outbound side as shown below. (Transactions – SXI_MONITOR/SXMB_MONI).

These messages do not get picked up automatically – and it is not possible restart them from using RWB or the transactions like SXI_MONITOR/SXMB_MONI.

Such messages could be processed in the following way:

• Send data directly to Integration Engine
• Change the status of failed message

This example shows how to solve the problem – two error messages are shown and one of them is solved here.

Step 1: Send data directly to Integration Engine

Go to Component Monitoring in SAP XI Runtime Workbench. Click on the Test Message tab for the Adapter Engine. Specify the URL of SAP XI Integration engine to send the message to e.g. http://<XIServer>:<J2EE Port>/sap/xi/engine?type=entry

Specify the header Information. Copy payload of the message using SXI_MONITOR/SXMB_MONI and paste it into Payload area in RWB.

Send the message using Send Message button.

Step 2: Change the status of failed message

Call the transaction SWWL.

Delete appropriate work items.

Check that the messages are complete in SXI_MONITOR/SXMB_MONI.

Another simpler way to accomplish this is to use transaction SXMB_MONI_BPE .  Select Continue Process Following Error under Business Process Engine -> Monitoring and Execute (F8). Update the selection criteria as required and Execute (F8). Choose the appropriate line item and click on Restart workflow button.

In these ways we can reprocess the messages failed on the outbound side. If the messages do not participate in BPM process, then they can still be traced via outbound queues or SM58 logs and restarted.

Hope this helps . Happy reading

Muhammad Siddique

Hello experts:

I have the following scenario I'm trying to build: Send information from a AbabProxy - PI - Jdbc through a stored procedure. It must answer a series of data, however the following error occurs through SXM_MONI.

com.sap.engine.interfaces.messaging.api.exception.MessagingException: Error processing request in sax parser: Error when executing statement for table/stored proc. 'Licores_Mayor' (structure 'Statement'): com.microsoft.sqlserver.jdbc.SQLServerException: No se encontró el procedimiento almacenado 'Licores_Mayor'.

My Data type are:

DT_EnvFactura_Out_XI

     Request

          factura

          localidad

DT_EnvFactura_In_JDBC

     Statement

          Licores_Mayores

               Action

               factura

                    isInput

                    type

               localidad

                    isInput

                    type

Herewith the mapping done to see if I can help in solving this problem

Thanks community.

1.     Introduction  and Business Requirement:

1.1.     We have seen lot of blogs/docs regarding SFDC and PI integration in SCN then what is new in this blog? Well, in this blog I would like to share my learning/experience on the integration of PI with SFDC in different approach which is very simple, easy and fast way to configure (initial set-up may take little time) and run the interface without any complexity. Without spending more time on what is SFDC cloud server and its CRM capabilities I will jump directly to business requirement/scenario that I am explaining in this blog as most of us know about SFDC.

          Client was having requirement to create eligible customers from SFDC to SAP ECC, Update back SAP customer number from SAP ECC to SFDC as response, Creation of Sales Orders from SFDC to SAP and Update SAP Sales Order Number/Date as response. There were lot of blogs/use case docs regarding SAP PI with SFDC integration in SCN. I followed the steps and  started implementing it in PI, but I felt little complexity in building this interfaces as we have to maintain Session IDs, two SOAP receivers, URL settings, Content type change etc. Then I had searched in SFDC Developers Force link, on how other applications are integrating with SFDC. I got some important info that using Java API generated from enterprise WSDL document provided by SFDC it would be very easy to integrate the SFDC with java applications.

          As SAP PI supports java mapping in Operation mapping, I started developing the code and leveraged it to login to SFDC server and do the DML operations by directly calling simple Java method calls without bothering on session IDs, SOAP message header, Server URLs, Content Type etc. At end, we successfully implemented these scenarios and they are running in production smoothly. So I thought to share this new way of integrating the SAP PI 7.31 with SFDC Cloud Server by leveraging the java mapping program to SAP Ecosystem Community so that others can also get benefit from this blog.

1.2.     Business Scenario:

          1.2.1. Retrieve all the new customer information from SFDC server having StageName field as 'Order Pending' and create the Customers in SAP ECC with retried data info and Update back the SAP customer number back to SFDC.

          1.2.2. Retrieve all the new Sales Order Information from SFDC and create Sales Orders in SAP with retried data and update the SAP Sales Order Number back to SFDC.

2.     Currently available solutions in PI:

2.1.     Third party REST adapters which ready to use to integrate with SFDC server.

2.2.     Third party solution/packages.

2.3.     Using PI SOAP Receiver adapters and adding session IDs in SOAP message header. Please check blog links given in reference section. These are little complex scenario and difficult to manage the sessions IDs.

3.     What is the benefit of this new approach (Leveraging PI Java Mapping):

3.1.     No need to have any PI SOAP Receiver adapters! in Integration Directory.

3.2.     No need to add session ID token in the SOAP message header as we are not going to use any SOAP messages at all! We will be to using SFDC java API calls that are generated from enterprise WSDL document.

3.3.     No need to have SOAP lookup code for retrieve the Session ID and No need to use Dynamic Configuration code to set the Sever URL, No need to use MessageTransformBean for changing the content type.

3.4.     Supports request and response messages using simple asynchronous interfaces (i.e. asynch-synch-asynch flow).

3.5.     Simple step to generate the APIs from SFDC enterprise WSDL document. Simple API call Connector.newConnection() to login to SFDC server, Simple API calls like EnterpriseConnection.Create(), update(), query() etc. for DML operations to process the data in SFDC server. Please see the java code below for further info.

3.6.     Simple steps to import Java mapping class, SFDC jars (enterprise.jar, wsc-22.jar) in ESR, simple steps to test the SFDC connection, easy  to troubleshoot as we can add custom log info using getTrace().addInfo() and re-throw the SFDC API exceptions back to PI Mapping runtime.

4.     About SFDC login and WSDL document:

4.1.     SFDC Server API login and Security Token: We use user id and password to login to SFDC server through web browsers, while connecting SFDC from applications e.g. PI, web services, applications need to login through API i.e. through SFDC API call, SOAP based/Rest based web service calls. While login to server through API, we need additional security password called Security Token along with your password. It will be alphanumeric long string that will unique to the particular user id which has to be passed along with password by appending it to password i.e. Mypassword+SecurityToken (without + char).

          You can generate/re-set this security token from SFDC server. Click on Personal Setup --> select My Personal Information --> Reset My Security Token. The new security token is sent to the email address of user.

If you are using any SOAP applications e.g. SOAP UI, PI SOAP adapter, you also need session Id to be passed in the SOAP Message header. You need to pass this every time while you hit the SFDC server and in some times, you have to maintain/manage this session IDs for complex transactions.  In our approach, we are login through SFDC APIs generated from enterprise WSDL, which does not require session ID to be maintained or to be added in the SOAP header! See 5.2.3 section for more info.

4.2.    SFDC Enterprise WSDL: To access the SFDC server’s Web services, you need a Web Service Description Language (WSDL) file.  SFDC provides the enterprise WSDL file to download from its server. Using this we can generate the APIs to login to SFDC server and do the DML Operations (Select/Insert/Update/Delete). We can download this WSDL by log in to your Salesforce.com organization and click Setup --> Develop --> API, right-click on ‘Generate Enterprise WSDL’ and save it in local drive, rename the file from .xml to .wsdl.

4.3. Generating Enterprise.jar using WSDL: First download the SFDC’s wsc-22.jar file from at https://code.google.com/p/sfdc-wsc/downloads/detail?name=wsc-22.jar&can=2&q=And to generate the enterprise.jar file, run the following command in command prompt. Provide the directory path of wsc-22.jar, enterprise.wsdl where these are stored and output directory path, make sure you have installed Java JDK 1.6+ in your system to run this command.

java –classpath pathToJAR/wsc-22.jar com.sforce.ws.tools.wsdlc pathToWsdl/WsdlFilename  pathToOutputJar/OutputJarFilename

e.g. java –classpath C:\SFDC\wsc-22.jar com.sforce.ws.tools.wsdlc C:\SFDC\enterprise.wsdl  C:\SFDC\enterprise.jar

5.     PI ESR Configurations:

5.1.     Below is Flow diagram of Retrieving SOs from SFDC updating in SAP data flow.

SAP side there will be a batch program running which will be scheduled in background, which will initiate the PI interface with asynch ABAP Proxy call. At receiver determination step, operation mapping is called and which in turn calls java program which does all the login to SFDC, issuing DML operations and processing of records returned from SFDC. Once DML operation is successful, java program forms the target message type structure and sends to receiver system. Since data is required at SAP ECC side, using receiver SOAP adapter in XI mode, asynch ABAP Proxy is called and forwards the records that is received from SFDC. Please refer below sections for java code.

5.2.     Java mapping code to login and to process SFDC data to do DML Operations:

5.2.1.     In SAP NWDS, create the class eg. PISelectSalesOrders which will extends the AbstractTransformation class so that it can override the transform() method. You need to import the enterprise.jar and wsc-22.jar file as library jars to compile the java code.

5.2.2.     Then next step is that in the transform() method, prepare a SQL Query string to be issued to SFDC Server, see below screen shot:

5.2.3.     Login to SFDC Server through API: Please check the below screen shot to connect to SFDC server by using Connector.newConnection()  method call, please note that, for password input you have send both SFDC login password appended with security token corresponding to the user id.

5.2.4.     Issue SQL query using connection.query(queryString) method by passing SQL query that you formed in previous steps and store the response from SFDC server in QueryResult object. Use getTrace.addInfo() after every operations so that you will get to know what step it crossed and it would be helpful in case of trouble-shooting.

5.2.5.     Process the Result using QueryResult object and form Target Message Type structure by using String builder object.

5.2.6.     Similar to above other DML Operations like create/Update and Delete can be used, in below screen shot you can see that code is updating back the SAP Sales Orders from SAP ECC to SFDC by using connection.update().

5.2.7.  Please note that from SFDC side, Opportunity.Id column is unique Id using which we can retrieve/update/delete the records in SFDC, so we need to store this value in SAP custom Z table (e.g. SFDC_Opportunity_ID field) when we first retrieve the data. Set the flags in Z table whenever we update back the SO number or customer number so that we should not update same records again and again.

5.3.     Importing SFDC jar files into ESR using Imported Archives: Once you are done with java mapping program and testing, import the generated enterprise.jar and wsc-22.jar files into ESR namespace using Imported Archives Object along with java mapping jar/zip file.

5.4.     Create the Operation Mapping in the ESR and assign java mapping program to it. Now we all set to do testing the connection and issuing DML queries to SFDC. Ready from ESR side.

5.5.     Before testing the java mapping make sure that you have disabled VM parameter -Djava.protocol.handler.pkgs=com.sap.engine.httpdsrclient.protocols|iaik.protocol as this will disable to use iaik security package as default security package. For connecting SFDC server using https protocol we need to use underlying Java security package.

6.     PI ID Configurations:

Since login and issuing DML commands are all happening in Operation Mapping (Java Program) there are only little configurations required at ID side.

6.1.     If we are having Update/Create Query (SAPàPIàSFDC) then we can use simple File adapter at Receiver side to complete end to end scenario and while interface determination, Operation Mapping would be called and does the Update/Create operation.

6.2.     If we are having Select Query (Batch ProgramàPIà SFDC for fetching data, SAPßPIßSFDC Updating to SAP) wherein we have to fetch all the records from SFDC depending condition and Update the retried data to SAP then we should have ABAP Batch Programà PIà ABAP Proxy scenario where operation mapping will fetch all the records and forma the target Message Type and it would be send across to ABAP Proxy. For PI point of view this transaction is asynchronous but in java mapping it is handling request-response messages.

6.3.     In case of any errors while login or DML operations, Java program would throw error with appropriate log and Operation mapping will get fail and interface would fail which will send out PI alert mail to respective support team.

7.     Summary:

In summary, using PI java mapping and SFDC enterprise WSDL document, wsc-22.jar and SFDC java APIs we can easily integrate the SFDC Cloud Server without worrying on Session IDs, SOAP Header, Server URLs and concentrate only on business logics and DML query.  I really enjoyed while writing java code after long timeJ, here with this I would like to conclude this blog. Comments are welcome.

8.     References:

1.     http://www.salesforce.com/us/developer/docs/api/apex_api.pdf

2.     http://wiki.developerforce.com/page/Introduction_to_the_Force.com_Web_Services_Connector

3.     https://code.google.com/p/sfdc-wsc/downloads/detail?name=wsc-22.jar&can=2&q=

4.     http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/50a76cfa-4966-2d10-aba7-da496d9b5bcf?quicklink=index&overridelayout=true

5.     http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/802f8d03-9282-2d10-52b4-f9446e077099?QuickLink=index&overridelayout=true

Hi,

This is a scenario of IDOC to File using xml HTTP port at sender side and also including IDOC bundling concept together.

First, let us see the configurations required for sender side.

Step1: Create an RFC destination of type H in sm59

Path prefix contains namespace, sender service and sender component (i.e. IDOC as sender service)

/sap/xi/adapter_plain/?namespace=XXX&interface=XXX&service=XXX&qos=XX

/sap/xi/adapter_plain/?namespace=urn%3Asap-com%3Adocument%3Asap%3Aidoc%3Amessages&interface=ZZIFS_OILDEB_XXXXX.OILDEB06.ZZIFS_OILDEB06&service=DWN_DEV_ECC_XXX_XXX&qos=EO

Step 2: Create an xml HTTP port in we21 TCode with the RFC destination created in step 1.

Step 3: Use the port created in above step in partner profile in we20 TCODE.

After you are done with the configurations in ECC system, now comes the ESR part.

Create data type , message type and service interface for receiver side. Create external message for sender side(IDOC bundling).

Next step is to create message mapping with IDOC as sender and File structure as receiver.

In Operaion mapping, the sender service interface should be IDOC only.

Now comes the ID part,

Step1 : Create 2 communication channels. One for sender and and one for receiver

For sender channel, adpater should be of plain HTTP type.

Please note that the message protocol should be of type XI payload in HTTP body

Receiver file communication channel is created as usually

The other pipeline steps are created in usual manner.

Create the Sender agreement, Receiver determination, interface determination and receiver agreement in usual manner.

TESTING:

Please trigger an IDOC from we19

Testing needs to be done from ECC(unit testing client).

Now check the results in SXMB_MONI

Then you can check in message monitoring of PI system and also communication channel monitoring from RWB

Note: IDOcs won’t be visible in idx5 of PI system because it will skip coming here and directly reach the target system

It won’t be possible to test the scenario through Integration engine of RWB, because it will throw internal error: 500 sender agreement not found.

Because it will directly hit IE, so it doesn’t require any sender agreement but in this case we need to use a SA.

Regards,

Rohini Potham

Hi Guys,

Most you will be wandering why to use mutiple PI system.Before joining my current project,I was working with only one PI system which was used to integrated all the different system.But there are few adavatages and features which will help you to understand working and features of Mutilple SAP PI system.

Background:-

Some client doesnt want their system to be accessed or exposed  by any other 3rd party system directly or you cant get in touch with your client system directly.In this case,mutiple PI Box will solve your requirement.

Here,if we want to access the data from client BW system or their ECC system than we have to go through client PI system,clearing all validation,filteration and mapping.

Let me introduce mutipling PI concept.Before that let me tell you those you are new to PI world one basic information or simple way to understand 3rd party:-Anythings which is in your landscape or in your network are your system and anythings which is outside your landscape or network is 3rd Party system(most of times in my initial days I used to get confused with this ). 

CRM,BW and ECC of both parties are connected to PI system which is here acting as a bridge between your landscape and client landscape.Depending on what kind of communication you want from this system,you can make them one way or two way.But PI to PI communication will always be 2 Way communiction as both inbound and outbound interfaces will run.

Client PI system is connected to their SAP ECC,BW or CRM.As per the business requirement if we want to fetch the data from client system  which is not allowed directly so we introduced the concept of mutiple PI system.

Now when you want to connect your PI system with customer you should use proxy communication,It will help you to communicate with your client system.

Please keep in mind that  validation and filteration of data can be  done at both the PI level.

Communication between SAP ECC or BW can be of any type.You can have IDocs,File or any type of communication within your landscape but PI to PI will be PROXY only.

Suppose you have one interface which is outbound to your system.In this case you have to create the RFC connection in your system and same needs to be done in Client system.Any mismatch in details will leads to failure of this interface.And same needs to be done in case of inbound interface.

Fetaures of Mutiple PI system.

1. Both Parties are well protected and no one can access your data directly without passing through PI system.Security is more.
2. Performance and throughput is high as interfaces are checked and validated at 2 levels.
3. Number of failed messages are less.

I would recomment that use of mutiple PI system is totally based on your business requirement.Most of the project doesnt use this features but if you are lucky and gets a chance to work with mutiple PI system.Please make best use of it.It will help you to increase your knowledge of PROXY(as proxy is widely used in this type of scenerio)and you will also get the chance to learn the UDF and Filter.  

Regards,

Abhinav Verma

The integrated Configuration(ICO) is recommended to be used in PI 730 because of the high performance of AAE. However the mapping error track mechanism is not as user friendly as that in ABAP stack. For the traditional ID contents combination in ABAP stack, no matter message mapping, java mapping or XSLT mapping is used, the error message can either simplly send out by throwing an exception or using <xsl:message/> and the error message will be shown in the ERROR tag in tcode: SXI_MONITOR. By analysing the error message in SXI_MONITOR is one of the most effective ways for a PI developer to locate the defect.

However when ICO is used, this becomes a different story. In the audit log of runtime workbench, the log just shows information like message is retrieved into the queue, the mapping is failed/successful etc. It won't display mapping error message, nor can it show the message from the exception directly. Java class like Abstracttrack cannot populate message to the audit log either.

I just found a way to write message from mapping to RWB audit log by using Java class AuditAccess. Wish you find it useful for you. Here is the tutorial when XSLT mapping is used. For message mapping or Java mapping, the process is almost the same.

Prerequisits:

1. you have to know how to use NWDI to develop Java class

2. you have to know how to create imported archive in PI ESR

3. you have to know how to get the source message id in the mapping process.

Steps:

1. download the JAR file com.sap.aii.af.ms.ifc_api.jar

2. create a Java class in NWDS and import the JAR file as the external source. Here is the Java source code ( i am totally new to Java. please ignore silly mistakes made in Java programming)

package com.xxx.util;
import com.sap.engine.interfaces.messaging.api.*;
import com.sap.engine.interfaces.messaging.api.auditlog.*;

public class errorLog {

public static void execute(String errorMsg,String messageid) {
  MessageKey key = null;
  AuditAccess audit = null;
  try{
   audit = PublicAPIAccessFactory.getPublicAPIAccess().getAuditAccess();
   key = new MessageKey(messageid, MessageDirection.OUTBOUND);
   audit.addAuditLogEntry(key, AuditLogStatus.ERROR, errorMsg);
  }catch (Exception e) {
   Exception me = new Exception(e);
  }
}
}

Info: there are two import parameters of the method:

a) The message you want to displayed in the audit log;

b) The source message id.

3. Create an imported archive by using the JAR file exported from the developed Java class.

4. In your XSLT mapping, insert the following relevant code:

     4.1 Add a namespace prefix definition like this

<xsl:stylesheet version="1.0" ....  xmlns:el="com.xxx.util.errorLog">

     4.2 Receive runtime constant messageid. For message mapping or java mapping, message id can be get by deriving dynamic configuration.

     4.3 Pass message by calling Java method

    <xsl:choose>

     <xsl:when test="function-available('el:execute')">

      <xsl:value-of select="el:execute($message,$MessageId)"/>

     </xsl:when>

     <xsl:otherwise>errorLog->execute is not available.</xsl:otherwise>

    </xsl:choose>

      info:

          Constant $message will be the error message to be displayed in the audit log;

          Constant $MessageId is the message ID from runtime

Here is the sceenshot of the result:

wish you find it useful. :-)