This blog topic has been a very common integration requirement in SAP XI/PI integration world and unfortunately there is no simple solution for this requirement. Some solutions were provided by forum experts such as run OS script (not actually using XI), using extra administrative scenario and checking for time stamp, using script with extra administrative scenario etc. The below discussions and blog will explain sample such requirements and solutions.

Links,

http://scn.sap.com/thread/1358164

http://scn.sap.com/thread/1507647

http://scn.sap.com/thread/1650060

http://scn.sap.com/thread/2016961

Grzegorz Glowacki’s blog - http://scn.sap.com/community/pi-and-soa-middleware/blog/2012/03/07/what-if-file-is-not-there-active-monitoring-of-once-a-day-sender-file-scenarios

I started thinking if this requirement can be achieved in a better way but yet with only classical configuration (no BPM & no extra administrative scenario). After some deep thinking, I came up with two ideas. One option is to use very simple alert to send email to business Admin user for failing sender channel indicating no business data for the day (ah, how sender channel can fail?). The second option is to configure an end to end scenario and send either actual business data or email accordingly (again how?). The below steps will explain my solutions.

Scenario:-

Steps:-

1. Obviously, we need a trigger file(.txt) which should be pooled in TEST mode by a scheduled Sender File channel as per business requirement.
2. The trigger file should have same structure as main business payload (.xml), but however with only one field . The field value will be very useful in evaluating conditions either in Receiver determination or in multi-mapping, to decide the actual receiver i.e., Target (or) an email to Target system business owner/administrator e.g., If Business data payload has <MT xmlns:ns0=”abc.com”><f1/><f2/><f3/>…<fn/></MT>, then trigger file can have data <MT xmlns:ns0=”abc.com”><f1>SendEmail</f1></MT>.
3. Two solutions,
   1. First simple solution:- Use "Additional files" option in sender file channel to pick up business data as a MANDATORY attachment. i.e., the file channel will fail with error if there is no attachment (actual business Data). Note:- With this solution, step2 trigger file can be empty or can have any dummy data
   2. Second Solution:- Use the same "Additional files" option in sender file channel to pick up business data but as an OPTIONAL attachment. i.e., the file channel will never fail with error when there is no attachment.
4. Now,

• For solution 3a,
  • configure a simple alert and send alert to the subscribed business user as an email indicating that there is no actual business data for the day
  • Use PayloadSwapBean to treat attachment as main business data and rest the configured scenario will take to send business data to target system
• For Solution3b,
  • - use PayloadSwapBean to treat attachment as main business data.
  • - With simple routing conditions (details as explained in step-2), now you can decide the actual receiver. Obviously, when there is no attachment for business data, the “SendEmail” condition will match.

    5.  Since File sender channel is configured in TEST mode, use script in the channel under “Run OS command after message processing” to archive the    business data(.xml) to ARCHIVE folder. Step 5 is common for both 3 a&b solutions.

I tested both the solutions and they are working like a charm for File NFS protocol. The solution can be extended to File FTP protocols as well but with a custom adapter module. The custom adapter module for FTP protocol should have functionality similar to "Additional Files" option in Sender File channel with NFS protocol. i.e., the custom adapter module should be able to attach actual business data and then it should archive after processing.

Hope this new solutions helps.

Regards,

Praveen Gujjeti

Recently we had a situation while implementing a synchronous scenario (HR system to third party web service).

As routine, we have received the same WSDL from the third party and the development is completed as per the documents/ mapping rules provided. Unfortunately the messages were failing. After approaching the third party web service team, they have just responded with Request type format and not with the response type messages.

We have verified the payload sent from PI box thru the TCP gateway tool with the data shared by the third party team and found that the name spaces and prefix are expected by third party are different than they generated in PI., the same have been handled thru the mappings.

Here the problem we encountered again, the third party has not provided the actual response messages to synch the messages with our mappings and we are not able to see the payload at PI level as logging is not available. There are some options like increasing the trace/logging, writing a module as mentioned by other SCN experts. But the problem only comes when you have limitations for doing something with the dependency of BASIS/other teams. We had same situation where we waited for long time for the our counter party teams to the needful for the required settings which had taken huge time, in the meantime, we have come up with an idea to find the response payload without increasing the trace level / logging in PI or without writing the module.

The simple activity we have done is, simply we have removed our response mapping steps from our operation mapping  and tested the synchronous interface from Sproxy, as there is no response mapping, without failure we have received the response message what being sent by third party as a response in proxy test. , and we are done with what we need.(The response payload is in ECC at proxy test).

(The below screenshot is taken from our Random tests and not related to the actual response payload).

Now time is saved as there is no dependency on other teams, and might be useful for who are not experts with java coding/module writing.

(The above blog is shared to provide as an alternative idea only and as per my favorite quote as "Every little helps”: and may have limitations based upon your PI scenario and system).

During testing phase of a project, there might be a scenario where SAP PI,PO or AEX 7.31/7.30 needs to be connected to SAP ECC’s multiple clients (say client 100 for Test Cycle-1, Client 200 for Test Cycle-2, etc. which might happen in parallel to each other) for sending and receiving IDocs.

SAP PI, PO or AEX Java IDOC receiver adapter can be configured using “RFC Client Parameters” as Manual, for which each SAP ECC's Business System will have IDOC receiver communication channel which will be pointed to their respective SAP ECC clients as shown below.

But for Java IDOC sender adapter it’s a different configuration for connecting to multiple clients of SAP ECC.

The only “RFC Server Parameters” available in IDOC sender adapter are

• Default (Recommended)
• Manual
• From NWA

When you configure as Default, which is by default one can connect to just one client of SAP ECC. For this you will be configuring in NWA the default inboundRA resource adapter by setting appropriate parameters and also creating the RFC destination (XI_IDOC_DEFAULT_DESTINATION) in NWA pointing the just one SAP ECC client.

When you configure as Manual, for which you can provide the appropriate parameters and create communication channel for each respective SAP ECC Business System for connecting each SAP ECC client. There might be a problem when you use this, as some security parameters which do not allow registering RFC server programs from remote host or a non-local host. The error is shown below.

Last parameter left is “From NWA”. So, before setting this parameter we need to create/clone resource adapter for each client which we want to connect. For this you need to login to NWA --> Configuration --> Infrastructure --> Application Resources, Create a New Resource Adapter.

Use Default Template “SAPJRATemplate”

In Application enter the name for the Resource Adapter. Here I am following a naming as “inboundRA_<SID of SAP ECC>_<SAP ECC Client>” ex. inboundRA_SID_100, and then click Next.

In JNDI Name enter the same name of Resource Adapter given in the above step and give some description for the Resource Adapter, and then click Next.

Click on “JCA Connection Factory Details”

Enter the JNDI a name. Here I am following a naming as “inboundRA_CF_<SID of SAP ECC>_<SAP ECC Client>” ex. inboundRA_CF_SID_100, and then click “Configuration Properties”.

Enter a Destination Name. Here I am following a naming as “XI_IDOC_DEFAULT_DEST_<SID of SAP ECC>_<SAP ECC Client>” ex. XI_IDOC_DEFAULT_DEST_SID_100, and then click “Save”.

Once Saved, the following Resource Names should be visible in Application Resources of NWA.

You need to add few properties to the Cloned Resource Adapter, so click on the Resource Adapter [Cloning] of inboundRA_<SID>_<Client XXX>. You can add property in the Properties tab by clicking “Add New Property”, after adding the properties save the Resource Adapter.

Add the following properties

Now we need to create RFC destination from SAP PI to SAP ECC, NWA --> Configuration --> Security --> Destinations

Create a new Destination of Type RFC

Destination Name – The DestinationName given in the Resource Adapter Property above XI_IDOC_DEFAULT_DEST_<SID of SAP ECC>_<SAP ECC Client>

Enter all the details of the Destination. Once all the parameters are entered, test the connection by clicking “Ping Destination”, make sure the ping is successful.

Now start the resource adapter.

NWA --> Configuration --> Infrastructure --> Application Resources

Filter the Resource Name of the Resource Adapter, select it and click on More Actions and click Start Applications you want to start

Click on Start

If successfully started, you should be able to see all the Resource Names of the Resource Adapter in Application Resources are green.

Now enter the Resource Adapter Name in the IDOC Sender Communication Channel.

In the SAP ECC system create a new RFC destination (SM59) of type T with a Registered Server Program for the each SAP ECC client.

Program ID – XI_IDOC_DEFAULT_<SID>_<Client XXX> (same name entered in the Resource Adapter property “ProgramID”)

Gateway Host – SAP PI/PO/AEX host (same name entered in the Resource Adapter property “GatewayServer”)

Gateway Service – SAP PI/PI/AEX gateway (same name entered in the Resource Adapter property “GatewayService”)

Save and Test the RFC destination.

Use this RFC destination when creating the IDOC port for sending IDocs (WE21) and use the port created in Partner Profile (WE20) in the respective test clients of SAP ECC.

References –

http://scn.sap.com/people/william.li/blog/2011/05/04/configuring-pi-730-java-idoc-adapter

http://scn.sap.com/community/pi-and-soa-middleware/blog/2010/10/21/pixi-pi-73-new-java-based-idoc-adapters-configuration-sender-receiver--teaser

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/29/ca36fa7f5544f6aa5808f1d3414184/content.htm

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/4a/5d28bcf2cb351ce10000000a42189b/frameset.htm

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

hi,

I saw many thread abput how to create a SOAP Lookup in PI since the standar fuction up today involves only the RFC and JDBC Lookup

until this point become standar, the only way to implent it is manually,

below you will find a detailed executed scenario to show you how to do it.

In this case i will use a simple structure that send two parameter to a service and it returns the sum of them.

so a Message Mapping needs to be created.

The same structure is used as source and target tomake this scenario more simple, as you can see a UDF was created (SOAP_LookUp) to invoke a service to sumarize boths values.

Libraries used:

import java.io.*;

import java.util.Map;

import com.sap.aii.mapping.lookup.*;

import javax.xml.parsers.*;

import javax.xml.transform.*;

import javax.xml.transform.dom.DOMSource;

import javax.xml.transform.stream.StreamResult;

import org.w3c.dom.*;

import org.xml.sax.*

Funtion CODE

*********************************************************************************************************************

AbstractTrace trace = container.getTrace();

String suma = "";

try {

//instace the channel to invoke the service.

Channel channel = LookupService.getChannel("CCR_SOAP_LookUP","cc_SOAP_Lookup_receiver");

SystemAccessor accessor = LookupService.getSystemAccessor(channel);

// The Request message in XML. THIS IS THE LOOKUP SERVICE

String SOAPxml = "<?xml version=\"1.0\" encoding=\"UTF-8\"?><ns0:SendDataToStorage xmlns:ns0=\"http://Test.Service.SchemaIn\"> <Valor1>"

+ var1

+ "</Valor1><Valor2>"

+ var2

+ "</Valor2></ns0:SendDataToStorage>";

InputStream inputStream =new ByteArrayInputStream(SOAPxml.getBytes());

XmlPayload payload = LookupService.getXmlPayload(inputStream);

Payload SOAPOutPayload = null;

//The response will be a Payload. Parse this to get the response field out.

SOAPOutPayload = accessor.call(payload);

/* Parse the SOAPPayload to get the SOAP Response back.   

   The conversion rate is available under the Field Name ConversionRateResult */  

InputStream inp = SOAPOutPayload.getContent();   

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();   

/* Create DOM structure from input XML */   

DocumentBuilder builder = factory.newDocumentBuilder();   

Document document = builder.parse(inp);  

  /* ConversionRate is available in the TAG ConversionRateResult in the Response XML */

NodeList list = document.getElementsByTagName("Response");

Node node = list.item(0);    

if (node != null) {

     node = node.getFirstChild();         

if (node != null) {   

suma  = node.getNodeValue();         

                       }   

}

} catch (Exception e) {  

  trace.addWarning("Error" + e);  }

1. trace.addInfo("Service XXX success executed");

return suma;

*****************************************************************************

Once all the configuration is made in the ESR and ID we can execute the scenario, in my case i will use the soft HTTP Client for SAP Process integration that could be dowloaded from: http://sappihttpclient.codeplex.com

Dont get confuse with the QoS, even if the Lookup is sync, the QoS of our interface is Exactly Once.

Message Monitor

to check whether the interface process success is let go to SXI_MONITOR to see what happened

so as fas we can see the scenario process sucess, so, lets check if the data process success in the adapter engine., so lets go to Runtime Workbech-->communication component--> adapter engine-->Communication channel monitoring.

Select the proper channel asocciated to our backen system press the USE FILTER buttom.

if every looks like the picture, click on "Message Processing completted ..." to get the payload of message

Once the popup comes up, go to Message Content tab and select the option "PAYLOAD........" from the drop-down-list. a message similitar to the below picture should be displayed.

and that it, hope you can get a more clear idea about how to configure such scenarios ussing SOAP LookUp

Landscape / System Details:

Target Audiance :

1. Consultant want to integrate Third-parties with SFSF BizX.

2. Consultant want to know How to call Client WSDL  in Java Mapping.

Document Objective:     

Sample Scenario : Query Employee Data from SFSF - CompoundEmployee Entity.

The document provides a step by step execution of test scenario "querying employee information from SFSF Biz X - CompoundEmployee Entity".

This process can be resused for other entities too.

Requirements as per FD :-

Implemented Solution :

All above said requirement can be full filed by using Employee compound application programming interface (API) for SuccessFactors' Employee Central.

The service is used to extract employee data out of Employee Central. This API allows you to easily integrate data with external systems and applications.

The API compound Employee selects multiple entities related to an employee and returns all data in hierarchically-structured response XML with the employee person data as the root node.

Select items

The select items are a list of all entities to be returned as part of the hierarchical query result xml. The restriction of fields is not supported.

The following sub-structures are supported:

person

personal_information

address_information

phone_information

email_information

person_relation

employment_information

job_information

compensation_information

paycompensation_recurring

paycompensation_non_recurring

payment_information

accompanying_dependent

alternative_cost_distribution

job_relation

direct_deposit

national_id_card

Where expression

The where expression can be used to filter the query result. The compound API does not support expressions with complex conditions on several fields and different logical operators.

The API supports the following fields and operators:

Field Remark Valid Operators

LAST_MODIFIED_ON

COMPANY_TERRITORY_CODE

PERSON_ID

PERSON_ID_EXTERNAL

COMPANY

EMPLOYEE_CLASS

DEPARTMENT

DIVISION

BUSINESS_UNIT

LOCATION

JOB_CODE

PAY_GROUP

EFFECTIVE_END_DATE

Note : There is no SAP ECC System involved in this Scenario.

Technical Solution:

This document explains the configuration of SAP PI scenario which can be used for query employee data. Entire process consisting of the login, logout, query and QueryMore operation on SF Side.

Above Screenshot: Integration solution to integrate Non SAP System with SFSF to File System using SAP PI Middleware.

Third Parties and SAP PI integrated through SOAP (HTTP) and FTP connector.

SAP PI to SFSF connection has been maintained in Java Mapping using  Java Class "SOAPConnectionFactory" class and its family.

All calls are Asynchronous in nature between SAP PI and Third-Party.

All calls are Synchronous in nature between SAP PI and Successfactors.

SFSF Demo Endpoint URL: https://salesdemo4.successfactors.com:443/sfapi/v1/soap

Above Screenshot: Operation Mapping has two mappings added in it

1. Java Mapping : Establish connection from Successfactor and based on Select request Query it will return the Intermediate Response XML Data.

2.Graphical Mapping : Perform transformation function returned response XML Data and finally pass it to Target File Communication channel.

Technical Solution

Step 1. Source System triggers the process with Select Query XML Data.i.e. here Source System is Webservice Navigator or SOAP UI.

Step 2. Data will be received to SAP PI using SOAP [HTTP] Sender adapter.

Step 3. Then this Select Query and SF Credentials XML Source Data will be passed to Java Message Mapping.

Step 4. Java Message mapping is written to perform Login , Query , Query more , Logout opreations and pass the Intermediate XML response / result to Next Mapping of Opeartion Mapping.

     4.1. A successful login will return a session ID as Lookup Response.

     4.2. Then this cookie must be passed back to all subsequent SF API Operation Calls in order to authenticate.

     4.3. Then we will call the Select Query Opeartion to fetch employee data. There is a limitation of 800 records in one call.

     4.4. We can check this on the basis of hasMore parameter. If it comes as true then we will call the queryMore operation to fetch remaining records on the basis of QuerySessionID parameter.

     4.5 Again there is limitation of 800 records in one call. So we will have to call step 4.4 in loop until hasMore paramter comes as false.

Step 5. Later Intermediate XML Data fetched during 4.1 to 4.5 step will be passed to graphical Mapping to handle the transformations and finally pass it to Target Communication channel.

Step 6.  Target Adapter or Communication Channel will create a Response XML file on FileSystem.

Important points to consider before setting up Integration scenario between SAP PI and SFSF interface are following :-

1. Opening firewall unidirectional port 443 from SAP PI to SFSF

2. Being B2B - Secure call this would need security Certificates in Trusted CA and WebStore.

3. You may not have Axis protocol in your SAP PI Box. Get it deployed explicitly.

Note : Please follow <Click Here> to get more information on above points.

PI ESR Object Development Overview

Source Message Type : Request

Message Type is created  to carry select query and username/password/company id from source side.

Select query can be dynamic all the time but should be in proper syntax.

Username-Password -Company will be used to get the sessionID from SFSF.

Intermediate Message Type : CompoundAPI_XSD

XSD is created based on structure similar to CompoundEmployee Entity and uploaded in External Defination.

You can use tool like Altova XMLSpy to handle such cases.

Target Message Type : Employee_Response_MT

Message Type is created on the basis of Target file Struture given in FD.

Create Outbound and Inbound Asynchronous service interface.

Name : WSDLCalling_Async_Out

Name: WSDLCalling _Async_In

Message Mappings:

Java Mapping : Source XML to Intermediate XML.

Establish connection from Successfactor and based on Select request Query it will return the Response XML Data.

Name: com/sap/integration/sfsf/CompundWSDLMapping_New

Graphical Mapping:Intermediate XML to Target Message Type.

Perform transformation function returned response XML Data and finally pass it to Target File Communication channel.

Name: CompoundAPI_MM

ROperation mapping - There are two message mappings in one operation Mapping.

Name : OperationMapping_WSDLCalling_JavaMapping

Due to Size limitation rest will be continued to PI.DOC - Successfactors BizX Integration using PI Java Mapping – Query Operation on CompoundEmployee Entity - Part II

This document is in continuation to my previous blog ->

PI.DOC - Successfactors BizX Integration using PI Java Mapping – Query Operation on CompoundEmployee Entity - Part I

PI Configuration Overview

Sender and Receiver logical business component representing source and Target System.

The business component contains sender interfaces and sender connector.

The business component contains receiver interfaces and receiver connector.

SOAP Sender Communication channel– Getting data from source system.

Name : CC_SOAP_Sender_SOAPUISessionCreate_EOIO.

File Receiver Communication channel– Store file on NFS / FTP System.

Name : CC_File_Test_LookUpData_Receive

Integrated configuration Object :

Testing Scenario:

Sample Source XML.

Message Mapping Test :-

Mapping Test :  1. Java Mapping - Source XML to Intermediate XML

Mapping Test : 2. Graphical Mapping - Intermediate XML to Target File Format

Sender System Application: Publish your WSDL on Service Registry.

Log in to Service registory.

Find the published WSDL with interface name.

Choose appropriate HTTP Port

Click Test button.

Enter Username – Password.

Choose operation name.

Populate required entries in Request Structure text fields.

Hit Next

Middleware - Message Monitoring :-

1.       Go to SAP PIMON

2.       Choose Message Monitoring

3.       Fill appropriate filter criteria to find theMessage

Middleware - Communication channel Monitoring :-

1.       Go to SAP PIMON

2.       Choose Communication channel Monitoring

Why this blog ?

Based on questions that have been received by customers of the Seeburger EDI-Adapters, Seeburger has now released the first version of an "Administrators Guide".

This is a guide, addressed to XI/PI system administrators running SEEBURGER solutions. It is  answering questions like “which directories on file system are used” etc... It is not provided on the release CDs, but it is available with the following SAP Note

Note 1893336 - SAP XI/PI Administrators Guide

-------------------------------------------

Feel free to take a look also at the other Guides that I have posted on SCN during the previous months.

(downloadable via SCN - check the Links below)

AS2-Adapter Guide focusing on Certificates/Troubleshooting:

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/03/19/certificate-and-troubleshooting--guide-for-seeburger--as2--adapter

SFTP-Adapter Guide:

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/05/29/sftp--certificate-and-troubleshooting--guide-for-seeburger--adapter

Log-Configuration-Guide:

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/04/09/easy-log-configuration--how-to-guide-for-seeburger-adapters

As always, any Feedback is highly appreciated, so that this Guide can be modified and be kept up-to-date.

Introduction

A comparision information on LSMW, Interface and SAP PI.

LSMW

Legacy System Migration Workbench as its name signifies is a SAP R/3 based tool which is used to transfer non-SAP ADHOC data into SAP. LSMW is a SAP tool designed to transfer non-SAP data into SAP once or to assist in the periodic mass-update of SAP Master Data. It requires a large amount of human input (i.e. it cannot directly interface with data sources and must be provided with an input file in a predefined format, it cannot automatically handle error conditions and must be re-run after manual amendments are made to the data in case of errors, and it cannot be scheduled on a recurring basis without custom development). Furthermore, there is no ability to monitor LSMWs in an automated way without manually checking each and every LSMW run. As a result, it is used for one-off data migration purposes or as a periodic business process to assist users in making large-scale updates to master data, but not as an integration tool between two systems and/or for processing transactional data.

The Legacy System Migration Workbench (LSMW) offers different technique for migrating data: Direct input, BAPI, IDoc, Batch Input Recording. While BDC basically uses batch input sessions and CALL TRANSACTION method.

BDC is traditional way of coding the transactions for uploading the legacy data, SAP is changing all transactions to Object oriented programming. Since BAPI is Object based and supports all the new transactions it is preferred over BDC. More over BAPI's process data faster than BDC.

BAPI is a SAP-supplied function module with a defined interface, which allows you to interact with various business objects. SAP guarantees the integrity of your database for anything updated using a BAPI. BDC is a method of driving screens programmatically, for updating SAP data. BAPIs are generally faster than BDCs." "A BAPI is faster because it is updating the DB ""directly"". Whereas BDC with call transaction goes through the whole screen sequence like any user would do, simply put, fills screens.

However - there is not always a BAPI for a particular transaction and not all functions that are performed by a transaction can be done by a BAPI. BDCs produce error sessions which can be processed by the user, while BAPIs don't. It is recommended to choose the BAPI first, if there is no BAPI then go for BDC

Interface

Interfaces are part of WRICEF - with the help of Interface the ECC system can communicate to other SAP and Non-SAP systems. An interface coordinates communication and input/output between systems that need to be linked together but reside on different operating systems; use different database solutions and different computer languages; or that are are legacy systems that are no longer supported by the vendor, while at the same time avoiding having to make sweeping changes to the existing applications or data structures, all while ensuring business continuity.

SAP PI

In SAP PI, the integration knowledge is shipped in the form of pre-defined integration scenarios. Furthermore, SAP PI provides a set of integrated tools for creating and managing all integration relevant information. The architecture focuses on the relevant application integration information centrally, with the usage type PI.  The benefits of SAP PI are as follows:

• Message monitoring,trouble shooting,scheduling,error handling,governance,common data model,out of box solution,performance monitoring,error monitoring
• Can integrate applications from one or multiple systems
• Applications can be company-internal, cross-company, SAP or non-SAP applications
• The modeling, administration, and automation of user-driven processes within SAP
• The process can be continued as a result of a particular action or event
• Execution of processes can be useful when integrating applications across system boundaries (without user actions), relevant functions within SAP are reused for this purpose
• Core function of the runtime is that it can save the state of a previously modeled process and call it up at a later stage

Comparision Table :

Comparision Summary

LSMW , The Legacy System Migration Workbench (LSMW) is a tool that supports data migration from legacy systems (non-SAP systems) to SAP systems in a initial load or ADHOC  methodology

The LSMW comprises the following main functions:

• Read's data (legacy data in spreadsheet tables and/or sequential files)
• Convert data (from the source into the target format)
• Import data (to the database used by the SAP application)

The LSMW supports a one-time transfer of data (initial data load and ADHOC) and also offers restricted support of permanent interfaces.The LSMW, however, does not include any functions for monitoring of permanent interfaces. The tool does not support any data export interfaces (outbound interfaces).

LSMW indirectly calls the BAPI, IDOC ,Standard & customized SAP programs by means of customized code, whereas SAP PI directly calls BAPI, IDOC and SAP programs. Since the call is direct & meta data residences in the SAP PI, it is preferable to send the data to SAP ECC from SAP PI. Apart from that, SAP PI has an out of the box solution for error handling & monitoring, message and end to end data flow monitoring.

In SAP PI, the scheduling, holding and storing of the message is possible, whereas in LSMW it is not possible. In the case of BDC, the LSMW is a better way than SAP PI, considering the commit and transaction security.

Recommendation

• Usage of SAP PI, for persistent interfaces
• Usage of LSMW for only BDC programs and where initial and ADHOC is involved

This blog outlines the situation where idoc acknowledgement status needs to be updated when the receiver is a webservice and is called using the SOAP adapter.

IDoc AAE communication channel was used on the sender

Asynchronous Scenario

In case if only system acknowledgement is required from an asynchronous scenario of posting to a webservice  then the following parameters need to be checked and updated :

1) Ensure that the persistence flag of the Java IDoc adapter is enabled in NWA.

2) The following parameter needs to be set in SOAP receiver communication channel.

1. XMBWS.GenerateSysAck – true

Synchronous Scenario

In some cases we have a requirement of updating the

This scenario basically shows the usage of RequestResponseBean where the response can be used to trigger a separate scenario. This was to enable tracking of the application acknowledgement message returned from the web service from idoc status tracking in ECC.The application message returned from the receiver sent back the original idoc number which was used to create an ALEAUD idoc to post into ECC.

For this purpose two scenarios were created – Scenario 1 triggering Scenario 2.

Scenario 1 : IDoc to SOAP Webservice request call

Scenario 2 : SOAP Webservice response mapped to ALEAUD

Scenario 1:

1) Create the first scenario in the standard asynchronous way with mapping and ID objects.

2) The only difference would be the receiver communication channel with RequestResponseBean adapter module as shown in the screenshot below.

3) This configuration will post the response to the Scenario 2 . The scenario 2 should be configured as follows :

Sender Communication Component – Receiver Business System of Scenario 1

Sender Service and namespace– by default this would be receiver interface of Scenario 1.

This is over ridden here by the parameter replaceInterface in the receiver communication channel of  Scenario 1 as shown in the screenshot above to match the sender interface and namespace of Scenario 2.

Scenario 2:

1. As mentioned above, the scenario 2 is configured using the same sender interface name and namespace as in receiver communication channel of  Scenario 1.
2. The important part is that the scenario should have the receiver system as virtual receiver as well – refer to the screenshot below (Thanks to the SAP consultant for showing us the way - without this guidance it would have been tough to get the resolution!).
   
3. This scenario has the receiver channel configured as IDoc Receiver for posting the ALEAUD idoc with the necessary mapping to map to the relevant idoc status.
   
4. Note that the sender communication channel can be dummy (so for example a dummy file channel can be used as well)  for this scenario as the response is placed in the pipeline directly by the Request Response Bean in the first scenario.

In case if the webservice returns standard fault messages and the requirement is to capture the same approach can be applied

using the following parameters in receiver communication channel of Scenario 1.

• interfaceOnFault - interface name for forwarding an application error message.
• interfaceNamespaceOnFault - interface namespace of the interface above.

Handling of a similar scenario in a different approach was  found in the link below – adding here for reference

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/03/25/requestresponse-bean-for-idocaae-adapter

Usage of Integration Flows for PI integration scenarios

SAP recommends using the newly introduced “Integration Flows” in NWDS (Eclipse). This is a very nice feature and has been described by Michal in the following blog:
http://scn.sap.com/community/pi-and-soa-middleware/blog/2011/11/09/pixi-eclipse-based-integration-flows--how-to-configure-them-with-pi-731

Problem Description

When you try to transport an integration flow which refers to a predefined communication channel you will get an error during activation of the configuration objects in the Integration Directory.

The key of the communication channel contains a business system. After importing the integration flow together with the communication channel for the first time, the key of the communication channel is adjusted correctly according to the transport group definition in the System Landscape Directory. However, the reference of the integration flow to the communication channel is not adjusted. As a result, the integration flow loses the link to the communication channel and the consistency check reports the following error: "Referenced channel | | does not exist" (please refer to the screenshots below).

The error occurs after transport of the configuration objects and integration flow to the target system (for example from PI development system to the PI quality system).

The following export procedure is usually followed:

1. Selection of the Integration Flow (integration scenario) via the export wizard:

2. Wait till the transport creation is confirmed:

3. After the transport has been released and imported into the target system via CTS+ and the objects are tried to be activated, the following error will occur:

Solution

After a lot of discussions with the SAP support, the error was finally confirmed and the issue was forwarded to the SAP BC-XI-IBC (Integration Directory) development and support group.

The new SAP Note is now available since August, 19^th 2013 describing the correction. Please refer to the following link for the note:

https://service.sap.com/sap/support/notes/1901073

Collection of (similar or different kind of) messages is a common requirement in any landscape and we are quite familiar with how to create such patterns using ccBPM - thanks to enormous wealth available on SDN, but since the existence of Process Orchestration approach of developing BPM scenarios has changed a lot which means no more ccBPM and eventually NW BPM has to take the onus of accomplishing these requirements.

So the objective of this blog is to show how we can create collect patterns using NW BPM in Process Orchestration.

Scenario Description:

The requirement is to collect as many as messages from the Source system for a certain amount of time and once the time limit gets exceeded split the collected messages (using multimapping) and send the same to different target systems.

Note - Splitting of collected messages can be done outside BPM also.

NW BPM Solution:

• First Message (send to BPM) will initiate the BPM instance and then active process will receive as many as source messages in an infinite loop for a specified interval of time.
• Each subsequent Message of same type send to active BPM instance will be collected under the ‘Collect Message' Intermediate Event (using the ‘Merge' assignment)
• To terminate the collection of messages, a Timer Intermediate Event with a specified interval of time has been defined so that when deadline is reached; the process stop collecting messages and send the collated messages to next step for further processing.
• "Split_Mapping" Automated activity is used for transforming/splitting the collected messages into two different target structures.
• "Target_Message1" and "Target_Message2" Automated activity will send output message from BPM to PI and eventually message will be delivered to Target systems.

Note - I am not explaining end to end BPM development, and the purview of this blog is very much confined to the NW BPM flow only. Having said that, in case you want to get acquainted with BPM development please refer Willam's article on the same:

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

Step Properties:

Start Step ->

"Collect Message" IME (Intermediate Message Event) ->

Same message trigger i.e. "Start_Message" is getting used in both "Start" and "Collect Message" IME

Source Messages are collected inside "Collect_Message" process context using "Merge" assignment

Exclusive Choice ->

Timer Event ->

I have defined 80 seconds of time interval to collect as many as business messages

"Split_Mapping" (Automated Activity) ->

I am calling message mapping inside NW BPM process to split collected messages into two different target messages (having different structures)

For more details on how to call mapping inside BPM, please refer below article:

http://scn.sap.com/community/process-orchestration/blog/2012/06/11/using-netweaver-pi-s-mapping-in-netweaver-bpm

Target_Message1 (Automated Activity) ->

First target message send to PI

Target_Message2 (Automated Activity) ->

Second target message to PI

In the next series (Part II) of this blog, i will try to explain how we can collect messages of different structures using correlation condition inside NW BPM.

Some of the key points,that can be considered for selection of SAP Process Orchestration ( SAP PO - Middleware )

• Central monitoring for message flow out of SAP ECC thru SAP PO
• Error monitoring for the messages flow out of SAP ECC thru SAP PO
• Centralized and standardized flow management leading to better security and reliability
• Common data model place holder
• Modelling and design of messages
• Transformations and cross-component integration processes
• Change real-time messages received from source system to batch processing to be delivered to the target system
• Messages that fail due to delivery errors can be configured to re-submit to the target system
• User management and security
• Validating the messages,cleansing and common format
• Converting from one format to another format
• To support the SAP standard functionality and Pre delivered code in SAP ECC
• For automated business process,scalability, archiving, admin, audit and orchestration

Introduction: In SAP PO Implementation, the segregation criteria for Business and Technical error

Technical errors: which are triggered by the system, these might be errors during file transfer due to a failed server, Connection failure, Communication errors, Infrastructure errors, Components down, Scheduling errors, Mapping error, etc

Business errors: which are triggered or handled by the application alone. An example would be a request for data about a material that is unknown in the receiver system, logical error, corrupted file, format errors, data conversion errors, process flow error etc

Error handling is essentially of interest in the synchronous case. In this case, an application can report application errors to the caller application. In the asynchronous case, we can capture an error that has occurred during transfer and forward an error to monitoring.

                                   Let us consider a flow from SAP ECC to Non-SAP thru SAP PO – Middleware

                    T1/T2/T3 are technical errors and will be handled by the technical team to resolve it

                    B1/B2/B3 are business errors and the process/business/functional team will work on that to fix it

          Depending on the business requirement we can either receive the error message as alert by e-mail, fax, or to other error monitoring tool and in each case we will also find the alert in SAP PI alert inbox. This is the inbuilt mechanism provided by SAP PI and it has to define certain steps like alert categories, alert rules etc for the service to get activated. Alerts can be triggered from various points in the message processing like mapping, Adapter issue and connection point of sender/receiver system and in the sphere of integration engine. The point where the alerts are triggered depends upon the interface and business requirements.

        Business errors are handled separately and vary based on business requirements per interface. Those errors can either be alerted/rejected/e-mailed on the record level or at the interface level based on the business requirements. The point of trigger also depends on the type and functionality of the interface. Errors can be reported at the adapter level, mapping or while routing. We have to design the appropriate mechanisms for each interface. We can also trace/log the errors for reporting them at the later stage by trading off between the performance and business requirements of the interface.

Hello Experts,

      I have scenario where i have to interface a handheld (bar code scanner)to the R/3 system?

       I know this is done using IDocs, but could you please give me technical details about it..

      If i want to use PI , how can i do it? any direct connection between the handheld and the system is possible?

    thanks in advance.......

Regards,

Anirban

                   SAP has a number of recommended best practices for selecting the appropriate integration method between its ECC and SAP PO environments and between PI and client business systems. The following sections describe the decision trees that have been specifically developed for the SAP ECC and SAP PO. These decision trees take into consideration the high level business requirements.

Protocol :

•     Proxy
•     IDOC
•     BAPI
•     RFC

All ABAP backend systems involved in a PI/AEX integration scenario need to be connected to the SLD. There are a lot of guides and overviews available on SCN how this is done. However, I wanted to create a complete overview in my blog since the existing blogs are still missing the one or the other detail I was looking for during my first SLD connection setup.

The following sections describe the SLD connection of an ABAP backend system to an AEX (Java-Only) 7.31 which also hosts the SLD (same hostname).

I. Overview

The main steps which need to be performed to set up a proper SLD connection are the following:

1st step: Definition of the SLD access data (hostname and user) which should be used to connect to the SLD on AEX

2nd step: Setup of the SLD data supplier connection

3rd step: Check of SLD connection

II. Detailed Setup Description

1st Step: Definition of access data:

The settings in transaction SLDAPICUST define where the ABAP system goes to read SLD data from if required. These settings have nothing to do with writing ABAP system data to the SLD. This part is setup in the 2^nd step (transaction RZ70).

     a. Start transaction SLDAPICUST

     b. Enter an Alias, the hostname of the SLD (AEX), port and the user to be used to connect to the SLD

        (standard SLD users are automatically created during installation of the SLD): 

     c. Enter the password for the used SLD user by clicking on the “Passwort” button.

     d. Test the connection by clicking on the "Test" icon. A green status should be displayed. If this is not the case,

         check again the hostname, port, user and password which you entered to connect to the SLD.

2nd Step: Setup of the SLD data supplier connection

The data provided in in transaction RZ70 define where the ABAP system is writing SLD system data to. It doesn't define where the ABAP SAP system reads SLD data. This is defined in transaction SLDAPICUST (see step 1).

As soon as the data is provided in transaction RZ70, the system automatically creates two RFC connections SLD_UC and SLD_NUC in transaction SM59 which are used to connect to the SLD. If these connections are manually deleted you can automatically recreate them by saving the settings again in transaction RZ70.

     a. Start transaction RZ70

     b. Enter the gateway hostname and the gateway service name. If you don’t know the correct values, choose the

         same as available in SLD at (see below screenshot):

         http://<SLD hostname>:<port>/sld
         => Administration => Details => Data Suppliers

        Enter the values in transaction RZ70:

     c. Start data collection:

         For immediate data collection click the start button, otherwise schedule a background job for regular data

         collection.

3rd Step: Check of SLD connection

     a. Start transaction SLDCHECK

     b. The SLD needs to open in a browser window and all status value need to be green

Background:

We recently completed SP Upgrade to our SAP PI7.3 system. Though there were no known issues during SP Upgrade/Post Upgrade Steps,

on activation of Objects in ID resulted in either Cache Update Failure or does not start.

Additionally, more details about this issue can be obtained from Application Server ST11 Trace.

From ST11 trace: User PIXXXXX (client XXX) has no ICF authorization XICACHE for executing /sap/xi/cache

Reason:

Its obvious now it is due to missing authorization issue.

Solution:

          • Make sure that Post Installation Steps are followed after SP Upgrade.

          • Ensure that the user has all the following Roles:

                          1. SAP_BC_WEBSERVICE_PI_CFG_SRV

                          2 SAP_SLD_CONFIGURATOR

                          3. SAP_XI_ID_SERV_USER

                          4. SAP_XI_ID_SERV_USER_MAIN

                          5. SAP_XI_ADMINISTRATOR_J2EE

          • Even after following Post Installation Steps judiciously, if the issue still persists,

                         1. On the Integration Server, execute transaction SUPC for SAP_XI_ID_SERV_USER(in your client) to regenerate possibly changed roles.

                         2. Once done, complete the USER COMPARISON under PFCG.

                             Hint: Make sure that Authorizations Tab and User Tab are in Green.

This should resolve the issue. Happy if this blog have helped you.

Suggested Links: http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/07/24/cpa-cache-refresh-403-forbidden--no-authorization-with-pidiruser-or-pidirsid#comment-383298

Suggested Notes: 1600539

All ABAP backend systems which need to be connected to PI/AEX need to be configured to ensure that PI is used as an Integration Engine for message processing. This blog gives an overview how the local integration engine of an ABAP system needs to be configured and what the most important options are.

1. Start transaction SXMB_ADMIN -> Integration Engine Configuration

2. Enter the role of the business system as "Application System" as shown below and enter the http-destination

    created earlier for connecting the ABAP system to the PI/AEX (out of transaction SM59) with prefix dest://

3. Goto Edit -> Change Configuration

4. In the following table, different runtime configuration parameters can be added, i.e. to increase the trace level, etc.

    The most important and recommende settings are the following:

     All other recommended runtime parameters are more optional ones which are usually used for development
     or test systems to increase tracing and logging. These are the following:

5. Make a check afterwards:

6. The status should be green at the end of the check:

To allow the usage of ABAP proxies in an integration scenario with AEX and an ABAP system,

the required RFC connections need to be set up accordingly on the ABAP stack.

The following blog gives an overview of the required steps.

Thanks a lot to Michal's blog which was the basis for my overview.

Overview

The main steps which need to be performed to set up a proper proxy connectivity are the following:

1. Connection to Enterprise Service Repository (ESR)
2. RFC connection to the AEX

Detailed Setup Description

1. Step: Connection to Enterprise Service Repository

• Start transaction SM59
• Create RFC-Destination of type “G” (HTTP-Connection to external server).
• Add a connection called “SAP_PROXY_ESR”:
• Add AEX server host name and port (port usually 50000)
• Add Path Prefix = “/rep“

• The user in the “Logon & Security” tab needs to be assigned to role SAP_XI_REP_SERV_USER

• The connection can be tested via transaction SE80 or SPROXY.

               If the ESR connection is not working, the following error message will appear:

               If the ESR is connected properly, the connected ESR is shown:
              

2. Step: RFC-Connection to the AEX

• Goto transaction SM59
• SM59 -> http Connection to ABAP System (Type H)

• Add AEX server hostname and port (usually 50000)
• Path is “/XISOAPAdapter/MessageServlet?ximessage=true"

• The connection can be tested by clicking button “Connection Test”

Steps to create LCRSAPRFC

1. Goto SM59 Tcode.

2. In node TCP/IP Connections (T), Create.

3. RFC Destination Name : LCRSAPRFC

4. In "Technical Settings" Tab,

    - Choose the option "Registered server Program"

    - Program ID : LCRSAPRFC_<SID>

    - Choose "Default Gateway Value"

    - In CPI-C timeout, Choose "Default Gateway Value"

    - In Gateway Options, Gateway Host : <Host Name>

                                        Gateway Service: SAPGW<Instance number>

5. Save.

6. Click on "Connection Test" button.

Note:  <SID> - Instance name of the PI/SolMan system hosted.

           <Host Name>  - Server Name where PI/SolMan system hosted.

            <Instance Number>  - instance number of PI/SolMan system.

                                                    Example : 00