Many a times we have a requirement where the client wants that any file which is send to external system should be archived on local file system/ FTP folder.

To take a backup of target file we have few alternatives available like we can opt a conventional way by adding one more receiver and assign one file receiver channel to it and then simultaneously send the message to third party as well as to the client's local system (let it be NFS or FTP), OS commands can also be one of the alternatives or we can write a adapter module to accomplish this requirement.

Recently I also came across the same situation, where SAP system is generating a message and after doing few transformations in PI I need to send transformed XML file message to external system and take a backup of the same target file on local FTP server.

Firstly I thought of adding one more "Business Component" (re-use the same mapping) and file receiver channel pointing to Local FTP folder in the existing scenario, but as expected client starts asking the same solution for multiple file interfaces . So to have a reusable kind of solution I created one generic adapter module which will create a backup of target message on local server and then send the same to external application.

So, the objective of this blog is to show how the target file message can be send to two different locations using one file receiver adapter.

Below module code has been defined in such a way that depending upon the parameters passed from channel it can back up a target message either on FTP or NFS server

package com.poc.sdn;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.rmi.RemoteException;
import javax.ejb.EJBException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import javax.ejb.TimedObject;
import javax.ejb.Timer;
import sun.net.TelnetOutputStream;
import sun.net.ftp.FtpClient;
import com.sap.aii.af.lib.mp.module.ModuleContext;
import com.sap.aii.af.lib.mp.module.ModuleData;
import com.sap.aii.af.lib.mp.module.ModuleException;
import com.sap.aii.af.service.auditlog.Audit;
import com.sap.engine.interfaces.messaging.api.Message;
import com.sap.engine.interfaces.messaging.api.MessageKey;
import com.sap.engine.interfaces.messaging.api.MessagePropertyKey;
import com.sap.engine.interfaces.messaging.api.XMLPayload;
import com.sap.engine.interfaces.messaging.api.auditlog.AuditLogStatus;
/*\*
\* @author amitsrivastava5
\*
*/
public class BackUpFilesBean implements SessionBean, TimedObject {

 /\* (non-Javadoc)
\* @see javax.ejb.SessionBean#ejbActivate()
*/
@Override
public void ejbActivate() throws EJBException, RemoteException {
 // TODO Auto-generated method stub
}
/\* (non-Javadoc)
\* @see javax.ejb.SessionBean#ejbPassivate()
*/
@Override
public void ejbPassivate() throws EJBException, RemoteException {
 // TODO Auto-generated method stub
}
/\* (non-Javadoc)
\* @see javax.ejb.SessionBean#ejbRemove()
*/
@Override
public void ejbRemove() throws EJBException, RemoteException {
 // TODO Auto-generated method stub

}
/\* (non-Javadoc)
\* @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
*/
@Override
public void setSessionContext(SessionContext arg0) throws EJBException,
RemoteException {
 // TODO Auto-generated method stub
}
/\* (non-Javadoc)
\* @see javax.ejb.TimedObject#ejbTimeout(javax.ejb.Timer)
*/
@Override
public void ejbTimeout(Timer arg0) {
 // TODO Auto-generated method stub
}
public void ejbCreate() throws javax.ejb.CreateException {
}
public ModuleData process(ModuleContext mc, ModuleData inputModuleData)
throws ModuleException {
Object obj = null;
Message msg = null;
MessageKey amk = null;
//Reading Type of Transport Protocol
String ServerType = (String) mc.getContextData("Server");
try {  
// Retrieves the current principle data, usually the message , Return type is Object
obj = inputModuleData.getPrincipalData();
// A Message is what an application sends or receives when interacting with the Messaging System.
msg = (Message) obj;
// MessageKey consists of a message Id string and the MessageDirection
amk = new MessageKey(msg.getMessageId(),msg.getMessageDirection());
//Reading file name from message header 
MessagePropertyKey mpk = new MessagePropertyKey("FileName","http://sap.com/xi/XI/System/File");
String filename = msg.getMessageProperty(mpk);
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS, "filename is" \+filename );
// Returns the main document as XMLPayload.
XMLPayload xpld = msg.getDocument();
byte\[\] inpbyt = xpld.getContent();
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS, "Input file read successfully"); 
//Archiving target file on FTP server
if (ServerType.equals("FTP"))
{
String HostName = (String) mc.getContextData("HostName");
String FTPDirectory = (String) mc.getContextData("FTPDirectory");
String Username = (String) mc.getContextData("Username");
String Password = (String) mc.getContextData("pwd");
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS, "Connecting to FTP location");
FtpClient client = new FtpClient();
client.openServer(HostName);
client.login (Username,Password);
client.cd(FTPDirectory);
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS, "Connection to FTP location Successful");
TelnetOutputStream out = client.put("Backup_"+filename);
out.write(inpbyt);
out.flush();
out.close();
client.closeServer();
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS, "File written sucessfully");
}
//Archiving target file on SAP file system
else if (ServerType.equals("NFS"))
{
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS, "Write file on NFS location");
String NFSDirectory = (String) mc.getContextData("NFSDirectory");
File path = new File(NFSDirectory+"/" +filename);
FileOutputStream fos = new FileOutputStream(path);  
fos.write(inpbyt);
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS, "File written sucessfully")
}
else
{
throw new CustomException("ServerType Parameter Is Not Having Valid Value");
}
// Set content as byte array into payload
xpld.setContent(inpbyt);
// Sets the principle data that represents usually the message to be processed
inputModuleData.setPrincipalData(msg);
}catch (Exception e) {
Audit.addAuditLogEntry(amk, AuditLogStatus.SUCCESS,
"Module Exception caught:");
ModuleException me = new ModuleException(e);
throw me;
}
return inputModuleData;
}
}
class CustomException extends Exception
{
public CustomException(String message)
{
super(message);
}
}

Module configuration to Backup file on FTP server

If target file needs to be archived on FTP server then below module parameters need to be passed in file receiver channel

Note - "Server" parameter value ("FTP" or "NFS") will call the corresponding method in module to archive files on FTP or NFS server.

Module Configuration to Backup file on NFS server

As explained athttp://help.sap.com/saphelp_nwpi71/helpdata/en/45/0c86aab4d14dece10000000a11466f/content.htmSAP PI 7.1 offers the possibility of controlling Communication Channels externally by using HTTP GET or POST request to the following URL:

http(s)://<host>:<port>/AdapterFramework/ChannelAdminServlet?party=party&service=service&channel=channel&action=action

This will require:

1. Assign the necessary permissions.
2. Enable external control of the desired Communication Channels in Communication Channel Monitor of Runtime Workbench.

Unfortunately in the help.sap.com link is not explained properly how the roles should be assigned. For that reason I found it necessary to create this document which explains in detail all the steps required.

1- Assign the necessary permissions.

Athttp://help.sap.com/saphelp_nwpi71/helpdata/en/45/0c86aab4d14dece10000000a11466f/content.htm are specified 2 roles that user needs:

• xi_af_channel_admin_display
• xi_af_channel_admin_modify

These are not 2 roles, but 2 actions that must be assigned to a specific role, and this role to the user concerned (for that reason many colleagues could not assign the specified roles, because these roles do not exists as such).

For assigning the necessary permissions follow the instructions below:

1. Enter Netweaver Administrator (http://<server>:<port>/nwa) and over Configuration Management --> Security select “Identity Manager”.

   b.  Select “Role” from drop-down list and select “Create Role”. In the Overview tab type a name and optionally a description.

     Then on "Actions assigned" tab on Available actions search for key *xi_af_channel_admin* and select the two actions needed, then select “Add”. Actions must be transferred to Assigned Actions at right side.

     Finally at “Assinged users” tab search for the user/s you want to assign the permissions and select “Add”. Then select “Save”.

2- Enable Communication Channels External Control at Runtime Workbench.

Enter Runtime Workbench (http://<server>:<port>/rwb/) and select “Display”. Then select “Adapter Engine” and finally “Communication Channel Monitoring”.

This opens a window in which we can search the Communication Channels that we must control externally. Once selected the desired Communication Channel will be seen that “External Control Off” is selected by default, for that reason it must be necessary change it to “External Control On”.

Now the channel will be enabled to be controlled externally. For doing this we use the URL:

http(s)://<host>:<port>/AdapterFramework/ChannelAdminServlet?party=party&service=service&channel=channel&action=actionsetting in ‘channel’ the name of the Communication channel to be controlled and in ‘action’ the value ‘start’ or ‘stop’ to activate/de-activate the channel.

When the HTTP GET/POST to the URL is made the service returns an XML with the new state of the Communication Channel.

Here is an example of how to stop a Communication Channel:

Then if we look at the state in Communication Channel Monitoring will see that the channel is stopped and we can see that the control of it is set to “External”

To start again the Communication Channel use the same URL but using the action ‘start’ instead of ‘stop’.

Now in Communication Channel Monitoring we can see that the channel is running again.

There is a third action we can use called “status” which is used to know the status of the Communication Channel. If you do not specify any particular channel in the service will return an xml with the state of all Communication Channels of Integration Directory. In addition you can perform such filters in order to check the status of all the Communication Channels that belong to a specific Communication Component using the “service” parameter.

Here is an example of status request for all Communication Channels of BS_TPI_00 Business System:

That's all. I hope you find useful this guide.

Alejandro.

The goal ofthis guideis to provide adetailed step by step to importXSD´s schemawithexternal referencesby using SAP PItool“Import External Definitions…”

In my case I have worked with a customer who uses OASIS UBL 2.1 as standard to Exchange messages (https://www.oasis-open.org/).

First, customer provides me the XSD nested structure in a zipped file.

Procedure:

All the schemasmust be importedunder the samenamespace to keep the reference amongst them.

Select the menu Tools > Import External Definitions… (We use the massive import tool).

This initializes a wizard

Select the Software Component Version and the Namesapace.

Choose all the XSD files to import, in this step isimportant to selectthe option'ImportAllReferences', so it will automatically reference the XSD's.

Click ‘Continue’, the message ‘Generate proposals…’ appears.

Finally it show the list of files to import, in the column name ‘Source’you can see those who has reference to other XSD file.

Sometimes it is necessary to modify a file name since PI doesn´t accept some characters.

At last click 'Finish'.

E.g. UBLContractNoticemain schema has reference to:

UBLCommonAggregateComponents

UBLCommonBasicComponents

UBLCommonExtensionsComponents

if some references are still missing, we will see fields in red on the message as shown in below example.

I hope you find useful this guide.

Recently, a new requirement come, I need to update the exsited mapping. But I don't want change the exsited mapping, so I duplicate the target node. And I find that the duplicate node also can map by repeat source node, and produce repeat xml instance node.

I share it to all of you.

XI is very power and beyond our imagine.

The second E101CRMXIF_DOC_FLOW is duplicated from the first one.

The mapping rule for the duplicate E101CRMXIF_DOC_FLOW

The result. The third and forth E101CRMXIF_DOC_FLOW come from the duplicate E101CRMXIF_DOC_FLOW.

Finally, my first blog post to SCN!

I was wondering when will I get a chance to write like the experts and finally here I am. I am really happy about it.

My blog post addresses a scenario to capture multiple Result Sets by calling a Stored Procedure.

I thought a sender JDBC channel would be capable enough to handle multiple result sets when a JDBC call is made to a Stored Procedure. But that was not the case. I tried a pass through scenario on a

Before we begin, there are few terminologies which need to be kept in mind.

Stored Procedure: A stored procedure is a subroutine available to applications that access a relationaldatabase system. A stored procedure (sometimes called a proc, sproc, StoPro, StoredProc, sp or SP) is actually stored in the database data dictionary.

Result Set: An SQL result set is a set of rows from a database, as well as metadata about the query such as the column names, and the types and sizes of each column.

Result List: This class is used in advanced user-defined functions (execution type "Context values" or "All values of a Queue") to return the result of a function.

System Setup:

PI: SAP PI 7.31

DB: MS SQL Server 2008

Assumptions and Pre-requisites:

• The DB resides on the PI server. If you wish to access the DB on a remote server using the code, you need to deploy the required JDBC Drivers on the PI System and have the required jars in place. In my case, the jar required is sqljdbc4.jar. Since the DB resided on the PI Server itself, it had the required drivers and jars already in place.
• Access to the DB is available. There is little basic knowledge required for writing a SP in DB.

Let’s Begin!

Stored Procedure:

The table name in DB is STUDENT_INFORMATION. The STUDENT_INFORMATION table looks like below:

My Stored Procedure looks something like as below:

CREATE PROCEDURE uspStudentDetails

AS

SELECT StudentName FROM<DB_Name>.dbo.STUDENT_INFORMATION

SELECT StudentGrade FROM<DB_Name>.dbo.STUDENT_INFORMATION

SELECT StudentNo FROM<DB_Name>.dbo.STUDENT_INFORMATION

SELECT StudentName FROM<DB_Name>.dbo.STUDENT_INFORMATION

SELECT * FROM <DB_Name>.dbo.STUDENT_INFORMATION

GO

Where <DB_Name> is the name of the data base being used on the MS SQL Server. Since there are 5 select statements in my SP, it will return 5 result sets. The output of each result is captured in each context (please see the output queue at the end of the blog).

I have generalized the UDF so that it takes the connection details, user id, password and stored procedure name as input to make the call to the DB and fetch the required details. The connection details are the same that you mention in your JDBC sender channel.

The general format of the Connection is: jdbc:sqlserver://<hotname>:<port>;databaseName=<DBName>

UDF Type: Queue

Input Constant Parameters: String[] db_connect_string, String[] db_user_id, String[] db_password, String[] storedproc_name

Output: ResultList[] result;

UDF Code:

try {

Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");

         Connection con = DriverManager.getConnection(db_connect_string[0],db_user_id[0],db_password[0]);

         String SQL = "EXECUTE dbo."+storedproc_name[0];

         Statement stmt = con.createStatement();

         boolean results = stmt.execute(SQL);

         do {

             if(results) {

                ResultSet rs = stmt.getResultSet();

                                                                ResultSetMetaData rsmd = rs.getMetaData();

                                                                 int numberOfColumns = rsmd.getColumnCount();

                while (rs.next()) {

                                for (int k=1;k<=numberOfColumns;k++){

                                                                                                                                                                                                result.addValue(rs.getString(k));

                                                                                }

                }

                                                                                                                                result.addContextChange();

                rs.close();

             }

             results = stmt.getMoreResults();

             } while(results);

           stmt.close();

      }

    catch (SQLException e)

                         {               

1. result.addValue(e.getMessage());

                            }

      catch (Exception e) {

         result.addValue(e.getMessage());

      }

Mapping:

Output Queue:

Since the length of the UDF was long I captured the first 4 result sets in one snapshot and the 5^th resultset in another snapshot.

The below queue displays the first four result sets captured from the UDF.

Output queue for result set 1 - 4:

The below output queue is in continuation to the above one.

Output Queue for Result Set 5:

Since this is my first blog, Please share your feedback and comments below.

Thanks,

Arkesh

In many projects I've seen using ASMA attributes, usually to retrieve the name of the file or the server from which a file have to be picked up. Every person who has used them at least once know how difficult could be performing unit testing for those attributes, especially in the early stages of the development when you don't have any real file or you cannot upload anything on the remote or local server for testing.

Recently I have discovered the possibility to Edit Messages in error directly from SXMB_MONI, by typing the command 'edit' in the command menu:

This will bring you to the web-based editor where, if you have the permissions (given by role SAP_XI_MESSAGE_MODIFY), you can edit the payload of the message and save it for re-processing:

The interesting feature is that you can edit also the additional attributes, like the dynamic configuration, in the same page:

Once saved, you can re-process the message in SXMB_MONI and get the desired result inside dynamic configuration

Of course, message editing is not encouraged in production systems unless really required and roles must be properly setup to restrict it.

Have fun!

Antonio

About the Survey

Focus of the survey is to collect the latest state of the positioning, use and organization of SAP NetWeaver PI and SAP integration in companies all around the globe. Target group are employees from companies using SAP NetWeaver PI as an integration platform.

The survey contains 23 general questions and 9 questions about this year’s special topic 'B2B and EDI'. Apart from minor adjustments, the general questions stay the same each year, so that the survey can also show changes in the use and positioning of PI over the years.

The global PI survey for 2013 can be found at the following URL:

http://www.surveymonkey.com/s/R2BBVLD

More information about the survey:

Global Survey for SAP NetWeaver Process Integration 2013

Current Status, new Target

This year's target was to reach a number of 400 participants, as there were less responses from some countries in 2012. Based on our figures from July 15th we achieved the number of 449 participants with still one more month to go. Therefore already a big thank you to all of you who have participated in the survey! New target is to set a new record with 500 responses till the end of the survey on August 24th.

Following a pre-release of two results as a motivation for all of you having not particapted in the survey so far.

Current Result: Number of participants based on user group / country

(As an appreciation of the exceptional number of participants from VNSG, we have kept the headline descriptions in Dutch)

Current Result: SAP NetWeaver PI release used in production

Feedback and planned Improvements for next Year

One feedback we got is that the survey form currently requires you to reply to all questions. In the next survey we want to make more questions and sections optional, as not each single topic may be relevant for or known by each participant. Another planned improvement is to make an easier distinction whether you are a participant from an enduser or whether you are a consultant working for an IT service provider or a freelancer. For sure, the survey in 2014 will also put more focus on SAP NetWeaver Process Orchestration and SAP NetWeaver BPM.

If you have other areas for improvement please let us know.

For more background about our interest group see our central blog International Focus Group for SAP NetWeaver Process Integration.

High Volume real-time integration/message processing has been a pain point of PI. I had been on a recent client, which had a requirement of processing around a million real time synchronous messages though PI predominantly via the SOAP Adapter for inbound and outbound web services.  Though a JAVA-only AEX based integration model was used, the initial performance testing yielded the following issues:

1. Frequent Message time-out in PI
2. Hanging threads/message blocking due to non-responsive Applications

Further research on performance tuning parameters, led us to the SAP FCA or Fast Connector Architecture threads.

What is the new SAP Fast Connector Architecture?

SAP Fast connector Architecture is a shared memory concept, based on memory pipes and MPI buffers.  The FCAServerThreadCount threads are used by the J2EE Engine to handle HTTP communication as replacement for classic dispatcher in older Netweaver AS Java architecture.

The above diagram summarizes, how an HTTP Request is processed on the JAVA application server

1.      HTTP worker threads wait for new requests in the HTTP request queue. If a request is in the queue, a free worker thread starts processing it.
2. The HTTP worker thread reads the request data from the FCA connection (based on memory pipes and MPI buffer).
3. The HTTP worker thread forwards the request to the associated container of the Java server process: Web container, EJB container, persistence layer, and so on.
4. The response is written to the FCA connection.
5. If the status of the session changes, the session table is updated in the shared memory (Web and EJB session).
6. Once the HTTP has been processed, the HTTP worker thread frees up the FCA connection and waits for new requests

How do FCA server threads eliminate “System Hung” Scenarios?

In a typical high message volume scenarios, all the worker threads on the PI JAVA stack, could be consumed by messages for a given source or target (this could be an SAP system or a 3rd party web server). In such a case, PI JAVA stack might seem to be hung, not processing any further messages.

The shared memory based FCA scheduler, maintains the state of such running threads. In addition it provides a mechanism to define the maximum thread consumption filter via the FCAServerThreadCount Property. In case any application exhausts the allocated thread pool, and subsequently receives another request, which runs for more than the specified time-threshold, the dispatcher assumes that the thread is hung.  Any further HTTP request for the same target receives an HTTP 503 from the application server.

This helps is maintaining the thread pools for messages related to any other application, thus enabling and protecting message parallelism.

The Max receiver setting can be done globally as well as for specific web resources via the ConsumerTypeIsAlias property.

Setting up the FCAServerThreadCount Parameter in PI (The default value is 15 per node)

Using J2EE Configuration Tool. The following are the steps:

1. Start the Configuration Tool.
2. Choose cluster-data - template - instance - <n> - managers - HTTP Provider Service.
3. From the list of properties, select FCAServerThreadCount.
4. Set the required maximum server threads as shown below. Parameter: FCAServerThreadCount to the desired value
5. Choose Set to apply the new value.
6. Choose Apply changes to save the changes.
7. For the changes to take effect, restart the cluster

We have a synchronous ICO scenario running on SAp PI 7.11 EHP1 EP6. A single SOAP sender adapter and 3 RFC receiver adapters. Routing is performed based upon the document payloads.

An R/3 system was running very slowly.In this scenario I would expect problems with users of one receiver but not all receivers as their R/3 systems were operating normally. Messages started to queue on the receiver because of the slow response. The interface utilises an ICO (Integrated Configuration Object) and the thread used by the sender adapter is retained until a response is returned. The SOAP comms channel used all available threads on all nodes. This resulted all inbound calls timing out

The following screen shot from Wily for the period in question and shows that the thread limit was reached on several occasions. This would indicate that timeouts were intermittent rather than continuous. Therefore, performance of the receiver system must have improved from time to time OR there were fewer requests being submitted.

Normal thread activity is as follows:

I checked the following notes to ensure that we don't block all interfaces for a specific adapter type.

Note 1493502 - Max Receiver Parameter for Integrated Configurations

Note 1136790 - Blocking receiver channel may affect the whole adapter type

Note 1557036 - Integrated Configuration Objects (ICO) scenarios use Messaging System Sender Queues only

Although these parameters have been set they only apply to receiver adapters and not sender adapters. In our scenario if each receiver channel is limited to two threads per node and we have three receivers then it would still be possible for the sender channel to attempt to consume more than the 5 threads per node thus causing timeouts.

Reference should be made to the document, ‘Analyzing Performance, Problems and Possible Solution Strategies. V2.0’ Section 6.4.2 ‘Only one thread is used to process the message and will not be available to other messages during the execution. ‘Section 6.2 ‘A bottleneck can usually be closely connected with a performance problem with the receiving system.’ Note 1593920 ‘For synchronous SOAP calls, the transmitter thread blocks until all the processing completes and returns a reply or the timeout value is reached’

I have created customer message and asked SAP to investigate why there is no control over the threads consumed by the sender channel. My concern, as I stated earlier, is not that this particular scenario will fail, we already know that will happen, but that all the threads for a particular adapter type; in this case the soap adapter could be consumed.

Recommendation

a) Ensure that individual sender communications channels cannot consume all the available threads for a particular adapter type. Awaiting feedback from SAP.

b) Individual scenarios with more than one receiver should have more than one sender adapter. This will ensure that any performance issues on a single receiver only impact the users of that receiver rather than all users.

Any comments?

One of the tenacious key areas that have to be focused while plumping for an EAI product is to gauge its robust error handling mechanism. This is the most recurrent trepidation raised by the customers while evaluating the SAP XI. Here I propose a very generic error handling mechanism that is supported by SAP XI for handling various types of errors that can occur in various phases of SDLC.

There is a first-rated white paper on Error Handling Framework in EAI by Dheeraj Saxena that can be used for brushing up the concepts. We pigeonhole the error handling into the following categories:
I. Error Handling at the Complete Landscape.
II. Error Handling at the Interface Level.
III. Re-Start Capabilities of SAP XI.
IV. Potential of Message Monitoring in SAP XI.

I. Error handling at the complete landscape :

Technical errors (Ex: Adapter Failures, Cache Failures etc) are informed during message processing through errors. Depending on the business we can either receive the alert by e-mail, fax, or SMS and in each case you will also find the alert in your alert inbox. This is the inbuilt mechanism provided by XI and it has to define certain steps like alert categories, alert rules etc for the service to get activated. However we do not deal with the errors that occur outside the SAP XI .Alerts can be triggered from various points in the message processing like mapping, ccBPM and in the sphere of integration engine. The point where the alerts are triggered depends upon the interface and business requirements. Configuring alerts is detailed in the appendix section and one can use the guide for configuring the alerts in XI.

Business and miscellaneous errors are dealt 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.

II.Error Handling at the Interface Level :

The Errors Handling can be categorised into following categories:

1. Business Error

2. Technical Error

3. Miscellaneous Error

1.Business Errors :

A. Error Type : Logic Errors.

Examples : Invalid combination of data ,Invalid trigger data, Business constraints violated.

Handling Mechanisms :

A.1Validation mechanisms that are feasible can be built to generate the logic errors in an interface through Adapter module/mapping programs/ ccBPM (if Exists) via an email or configuring alerts in adapter monitoring of runtime work bench.

A.2. Depending on the criticality and type of the error, an appropriate error message with the error code can be mailed/alerted to the application support help desk.

B.Error Type : Format Errors.

Examples : Blanks not explicitly padded with spaces for character data ,Date format errors, File/Data Structure Format errors.

Handling Mechanisms :

B.1. Messages might be validated for uniform format errors that are business critical and some errors might be handled but if there is a huge disparity then the message is eroded out and notified to the application support helpdesk.

C.Error Type : Data Conversion Errors.

Examples : Lookups not available with specified keys, Error in mapping between disparate data types.

Handling Mechanisms :

C.1. For adhering to the performance standards we do not really lookup for dynamic values.

C.2. Mapping errors can be raised if required by business and an alert is triggered to the middleware support desk for correcting it who can request the source to re-send the message in case of data errors. We will define both source and target field data types as a string in case of disparity between the data types that will avoid errors of these kind.

2. Technical Errors :

A.Error Type : Communication Errors.

Examples : Database connections lost, Unable to execute transactional calls due to target system unavailable

Handling Mechanisms :

A.1. If the target system is unavailable and the data has to be pushed onto XI adapter (Ex: Sender File Adapter) then the target system has to re-send the data when available.

A.2. If the data has to be pushed from XI then messages are re-sent depending on the QoS of the configured adapter.

A.3. Transaction integrity is guaranteed by XI adapters as duplicate messages are not triggered from adapter queue.

A.4. The receiver system availability cannot be checked prior to sending the data from Integration engine to adapter engine but the data can be resent using manual or automated mechanism. The Interface has to be asynchronous for the data to be resent.

B.Error Type : Infrastructure Errors.

Examples : High disk usage stopping event persistence, High CPU usage bringing components down, Network related errors, Errors related to client libraries for remote calls in client server computing.

Handling Mechanisms :

B.1. Infrastructure errors can definitely happen when huge messages arrive at XI. Integration and adapter queues might get stuck due to which all the incoming messages from the other interfaces can be blocked. To avoid clogging we might design a distinct queue to handle it.

B.2. Queues can also be clogged if more messages arrive at XI and get stopped. Integration Queues can be re-started manually through smq1, smq2, smq3 transactions. Adapter queues can be re-started manually through adapter monitoring of the runtime work bench.

B.3. We can track the remote errors through the adapter monitoring provided by the runtime workbench.

3. Miscellaneous Error :

A.Error Type : Components down.

Examples : Executable components are down due to technical /infrastructure errors.

Handling Mechanisms :

A.1. Integration Engine or Adapter Engine or cache failures are reported to the support desk through the alerts.

A.2. Required How-To-Guides are provided in the upcoming series if the systems are not configured appropriately. This is SAP administration activity.

B.Error Type : Username / passwords changed and so on.

Examples : Login Information changed without changing configuration in connection utilities.

Handling Mechanisms :

B.1.This is the usual case in the File/RFC adapters etc. and the adapters might not work as the new username/passwords are not configured. We have to use the features provided by SAP XI latest versions to configure them centrally and dynamically.

C. Error Type : Scheduling errors.

Examples : Externally controlled batch job fails to execute .For Example; there could be a multi-step job.

Handling Mechanisms :

C.1. Jobs can be scheduled through event driven monitoring and job failures can be reported either via custom report or e-mail or alerts to the support desk.

C.2. However a job schedule error in the application system is not handled by XI team.

D. Error Type : Time constraint errors.

Examples : Certain actions are coded to time-out after specific intervals.

Handling Mechanisms :

D.1. Timeout exceptions can be triggered if we have to collect and bundle messages through the deadline monitoring branch of ccBPM.

E. Error Type : Threshold Errors

Examples : In certain scenarios , it might be required to throw an exception in case the total number of errors exceeds a certain threshold value. Handling Mechanisms :

E.1. The threshold value varies from project to project and can be set and alerted via an email using the alert mechanism of SAP XI.

CPA Cache refresh fails in NW 730 and NW 731 with PIDIRUSER or PICACHEUSER with message 403 Forbidden - No Authorization.

When you perform the CPA Cache refresh with the PIDIRUSER or PIDIR<SID>, It says that 403 Forbidden - You are not Authorized.

You have referred the SAP Note Note 1232259 - Security Note: Cache refresh with user change and made changes to the user roles. You have created ABAP RFC destination SAPXICACHE<client> and also followed SAP Note : Note 1673399 - PI Upgrade: No RFC authorization for user PIDIRUSER. Still You are facing the No Authorization issue.

The solution to this problem is to update the XI ADAPTER FRAMEWORK component to the latest patch level with the current support stack or if possible to the latest support stack level in your system.

It is no longer possible to call this page with a service user (for example PIDIRUSER or PISUPER). The Full CPA Cache refresh has to be performed with a Dialog or a System user.If possible, you can take help from security team to change the PIDIRUSER to a system user.

In addition the Role 'SAP_XI_ADMINISTRATOR_J2EE' needs to be added to the PIDIRUSER, along with the below mentioned roles.

SAP_BC_WEBSERVICE_PI_CFG_SRV

SAP_SLD_CONFIGURATOR

SAP_XI_ID_SERV_USER

SAP_XI_ID_SERV_USER_MAIN

A full CPA Cache refresh has immediate impact on the message processing. On large systems a full CPA cache refresh can take up to an hour. During this time only restricted message flow is possible.

The history of all CPA Cache updates and the current content can be displayed by the following URL:

http://<host>:<port>/CPACache/monitor.jsp

For further details, you can refer SAP notes

1592426 PI SEC: Unauthorized use of administrative functions in PI

1600539 - PI AF: Manual Execution of a CPA Cache Refresh

Thanks,

Kasi Vishwanatha Gupta

In January, I had created the following blog about setting up a B2B End2End-Scenario with the Seeburger EDI-Adapters.

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/01/13/quick-setup

It explains the basic concept of handling EDI-Data with the "Classifier/BIC/Splitter" approach.

In the meantime, I got a lot of direct feedback to this scenario and the question, to create something similar als for the new PI environments (especially for PI 7.31 Java Only, which is the system that I am using in this scenario together with the lastest release 2.2 of the seeburger EDI-Adapters).

So in this blog, I am describing another scenario where an ANSI X12 850 file is received via AS2, processed through the PI-System and forwarded to the SAP Backend. Additionally a 997-message (Acknowledgement) is also created and sent back to the original Sender of the 850 message.

The focus is hereby completely on the "Integrated Configuration" and not on the settings in the channel (Classifier/BIC/Splitter). If you have questions to this, please refer to the mentioned previous blog.

Introduction to the Demo-Scenario :

The following picture describes the case, where the customer "Mex_Electric" is sending an 850-message via his AS2-Provider "Mex_AS2Provider" to an SAP PI-Server PIJ and receives back the 997 message.

The Testfile looks like this:

Involved Parties :

The following 3 Parties are setup on the system PIJ.

The Parties starting with "EDI_SP" are used for the AS2 transmission, while the party "EDI_BP" refers to a Business Partner.

1. ) EDI_SP_Mex_AS2Provider

The Party "EDI_SP_Mex_AS2Provider" is the Sender of the message (using AS2).

It includes the AS2-ID of the partner...

...as well as the required channels (to receive the data and to receive the MDN)

2. ) EDI_SP_PI731_AS2HUB

The Party "EDI_SP_PI731_AS2HUB" is only used for the AS2-data-exchange (to hold the AS2-ID of the PI-Server.

(there are no channels assigned to this Party or the corresponding AS2-Component)

3.) EDI_BP_Mex_Electronic

This party is used to process the real business data (ANSI X12 850 V4010 messages) after the "Classifier/BIC/Split" - Handling has extracted the real data for further processing:

The party includes a Communication Component "BC_9876543210987", referring to the Sender-Code in the ISA-Segment, as well as the Interface and the Split-Channel.

Setup of the Integrated Configuration

The scenario consists of 2 different cases of the "Integrated Configuration".

Part 1 -  Receiving the data via AS2 and sending back the corresponding Functional Acknowledgement (997)

Part 2 -  Processing the 850 data to an ORDERS05 IDoc and transmission to SAP Backend

...and an additional option,  to use an Integrated Configuration to process the MDN is described at the end of this blog.

Integrated Configuration for Part 1 :

"Receiving the data via AS2 and sending back the corresponding Functional Acknowledgement (997)"

The initial screen of the Integrated Configuration includes the Sender/Receiver-Parties (which contain the AS2 IDs) as well as the inbound Channel and all required certificates/keys to receive the data via AS2 (using signing/encryption)

The inbound channel executes the "Classifier/BIC/Splitter" (please refer to the earlier blog for this concept). As a result, the Functional Acknowledgement is created as MainDocument and can be processed furtehr to send a 997 message back to the Sender of the data. (Mex_AS2Provider)

A Mapping is executed to transform the FunctionalAcknowledgement to a 997 message.

(other options would be the EDIFACT CONTROL or any custom-defined report/acknowledgement )

In the last step of the "Integrated Configuration" , the Channel is selected to send the 997 message back to the original sender of the ANSI X12 850 message.

Beware:

A Header Mapping is needed, to use the correct AS2IDs for this transmission (as now the AS2HUB is the Sender and the Mex_AS2Provider is the receiver)

Integrated Configuration for Part 2:

Processing the 850 data to an ORDERS05 IDoc and transmission to SAP Backend

To process the 850 data, the initial screen of the Integrated Configuration refers to the inbound Split-Channel which picks up the "split attachment" that was created during the "Classifier/BIC/Splitter" - Handling while the file had been received via AS2.

As receiver of the messages, I have in this case specified two different SAP Backend Systems (SER; SEO)

For each system, a mapping will be executed to convert the 850 to an ORDERS05-IDoc

For the Outbound Processing, an IDoc_AAE-Adapter Channel is used to transmit the ORDERS-IDoc to the SAP Backend(s)

Result in the Runtime Workbench:

In the Runtime Workbench you can see the following lines :

1.) File received via AS2 from Mex_AS2Provider and 997 sent back via AS2 to Mex_AS2Provider

2.) 850 attachment translated to an ORDERS-IDoc and forwarded to system SERCLNT800

3.) 850 attachment translated to an ORDERS-IDoc and forwarded to system SEOCLNT800

Additional Configuration possibilities:

(processing inbound MDN messages via Integrated Configuration)

If the partner "Mex_AS2Provider" is requested to send a MDN back (to confirm that he has received the 997 successfully via AS2) and if the MDN shall be processed also in PI (e.g. to update a status message in the SAP Backend) an additional "Integradted Configuration can be setup to pick-up and process the Delivery Notification:

Making History, SAP Netweaver Process Integration 7.1 comes with the feature of XML validation requested by customers. It is important to test the XML message for a predefined schema, especially when using industry-specific adapters, such as Rosetta Net. XML validation allows you to check the structure of an XI message payload. The structure check is dependent upon stored data types.

Now, validation can take place in either the Advanced Adapter Engine or Integration Server but depend where it take places the system reacts in different.

The data types used for validation come from Enterprise Services Repository since PI 7.3.

During runtime, the target adapter translates an inbound message into the required PI message. The range of adapter functions allows the system to compare the payload to a configured schema. The adapter calls a central component for syntax validation, which calls an XML schema validation engine.

If the system detects an error, the Advanced Adapter Engine triggers an exception, stops the further processing of the message, and uses a synchronous response-call to inform the sender of the error. Industry-specific adapters inform the sender asynchronously, as is required by the RNIF and CIDX protocol.

The Advanced Adapter Engine does not make the message persistent; it can trigger an alert.

Even when the Integration Engine checks the XML structure, the data types come from Enterprise Services Repository. They must be exported by the Enterprise

Services Repository and copied into the file system. For the inbound and outbound processing of messages, XML validation is a new step in the pipeline. Whenever the structure of a message does not fit the stored schema, the Integration Engine creates an error description containing status information and a list of all structure errors. The error report is saved. The message is given an error status. The sender is not automatically notified when a message is validated in the Integration Server.

The Integration Server makes the message persistent and can trigger an alert. An administrator can continue to process the message using the Runtime Workbench and can restart the process, if necessary.

It s possible also,to check the schema in the receiver side so, In the receiver agreement, you can set the validation in the Integration Server.

When validation takes place in the Integration Server, a message is set to the error status in the event of an error and can be processed by the administrator in the Runtime Workbench.

in theory it looks perfect, but how to implement it for real? see the steps below to configure it.

You make available in the file system the schemas that should be checked by the Advanced Adapter Engine or Integration Server. The prerequisites for this are:

• You have created the RFC destination for AI_VALIDATION_JCOSERVER on AS ABAP and AS Java.

• You have the authorizations required for accessing and changing the directory structure for XML validation.

• You must have access to the schemas that are referenced using the Import namespace tag in the main schema.

Proceed as follows if you have PI 7.1. Remenber that with PI 7.3 there is no need to follow those steps because the schema is taken from the ESR

1. For XML validation, you must save the required schemas from Enterprise Services Repository in the file system by creating the following directory

structure.

Create the following directory for validation on the Integration Server in the <sysdir> /xi/runtime_server directory. /validation/schema/<GUID

for the software component version, to which the service interface is assigned>/<Repository namespace of the service interface>

Create the following directory for validation on the central and decentralized Adapter Engine in the <SAP Installation directory>/<System

ID>/<Instance number>//j2ee/cluster/server0 directory for non-cluster installation of AS Java: /validation/schema/<GUID of the software component version, to which the service interface is assigned>/<Repository namespace of the service interface>.

For cluster installation of AS Java, create the directory structure mentioned above and save it in the corresponding server node directories.

2. Convert the <Repository namespace of the service interface> into a valid folder name by changing the following characters to "~": /,\,:,*,?,",<,>,|,;,,,=,&,%,[,],# . If there are several special characters in a row, replace them with a single "~". For example, "A%&B" changes to "A~B". Periods (.) at the end of a name are automatically deleted.

3. Create the /<Service interface> directory in the directory structure mentioned above.

4. If the schema contains the targetNamespace attribute in the XSD definition, proceed as follows:

     • Create the /<targetNamespace> directory in the directory mentioned above.

     • Repeat step 2 to convert <targetNamespace> into a valid folder name.

     • Export the schema and save it in the /<targetNamespace> directory.

5. If the targetNamespace attribute does not exist in the schema, export the schema and save it in the /<Service-Interface> directory.

6. If the main schema contains references to other schema by using the import namespace tags, proceed as follows:

     • Create an /<import namespace> directory for every referenced schema in the /<Service-Interface> directory can be found in the Enterprise Services        Repository on the WSDL or XSD tab pages.

     • Repeat step 2 to convert <import namespace> into a valid folder name.

     • Export the schema (XSD file) indicated by the <schemaLocation>attribute.

     • Enter the name of the schema indicated by the <schemaLocation> attribute as the file name. (For example, if schemaLocation="       

         http://www.w3.org/2001/xml.xsd", then xml.xsd is the name of the file.)

     • Save every referenced schema in its corresponding directory /<import namespace>.

Summary

This document will help us in understanding and achieving the following scenario by using Java Mapping

Scenario:

• SAP PI receives a .csv file as an attachment.
• The attachment needs to be read ,converted in to XML and place the XML file in the target location
• The .csv file contains multiple records with 2 fields in each record

  Note: The above scenario can be further enhanced based on the requirement.

Prerequisites

·        Java and PI Knowledge.

·        SAP PI 7.31(Single Stack),SAP NetWeaver Developer Studio 7.31 SP07,Java Version 1.6.

Details

PFA Java Mapping Code and test sample files for reference.

ESR Configuration

Source Message Type

Target Message Type

-          Create Outbound and Inbound Service Interfaces and assign these message types.

    Note: For Outbound Interface, Please choose Interface Pattern as: Stateless (XI 3.0- Compatible)

-          Import the java mapping in ESR under Imported Archives

-          Create Operation mapping and assign the java class from the imported archives as shown below:

Please check Read Attachments check box in Operation Mapping

In Integration Directory, you can configure a simple File to File scenario

Note: While configuring the sender file adapter, make sure Additional File(s) section is selected under this section you have to mention the csv file name that will be picked as an attachment or you can refer to my blog http://scn.sap.com/docs/DOC-44537where in an customized adapter module is being used to achieve this functionality.

Sender FILE Channel Configuration

NFS location contains the following files

Sender Channel is started and the following audit logs can be seen in the Audit logs

Message Monitoring Logs is as shown below . Here, in the below screenshot , you can see the File.csv coming as an attachment in the payload.

Following is the output of Java mapping

This simple blog would give you some points noted for XI/PI Maintenance activities.

During Maintenance stopping all Communication Channels will still enable the HTTP /IDOC transactions flow.

This at times would bring overhead to the ongoing Maintenance process and suspicions about running interfaces.

We could avoid the situations if we include the point of Deactivating the queues/Shutdown the Integration Server completely.

This simple activity above would confirm the PI sytem shutdown completely and to avoid any overheads during regular maintenance.

Lock the Integration Server for incoming messages by calling the transaction Integration Engine - Administration (SXMB_ADM) and choosing Integration Engine Configuration -> Specific Configuration -> Change -> New Entries. Select the category RUNTIME and then the parameter ENTRY LOCK: Set the current value to 1 (LOCKED) and choose Save.

Note: If you set this parameter, messages that have already been
received will still be processed. By locking the inbound queues you can ensure that all messages arriving prior to setting the lock will still be processed. For this you have to wait till no more XI outbound queues are visible in transaction SMQ2 and all the messages are processed in the Adapter Engine. This waiting time will of course result in additional delay of the shutdown process.

Deregister the queues of the XI system directly by using transaction SXMB_ADM -> Manage Queues. Select the radio button "Deregister Queues" and then the button "Execute action". By doing this the processing of all messages in the queues will be stopped immediately. Monitor the remaining entries in the queues by using transaction SMQ2 until no more queues are listed.

Related SAP Notes 870864

Part 2 goes into how to make the necessary changes for 2013

https://websmp130.sap-ag.de/sap/support/notes/1808938 (SMP log on required) details the steps to take if you are using the Configuration Wizard.

The standard configured integration scenarios in the delivered content are:

Whilst waiting for SAP to release either content or configuration guides, I had to configure the following scenarios:
Employer Payment Submission (EPS)
Full Payment Submission (FPS)
Employee Alignment Submission (EAS)
Early Year Update(EYU)

First things I did were having to find the 2013 content based upon the documents in the above note.

HR_GB_EFO_FPS_OUT_13 <> HR_GB_EFO_FPS_IN_13

HR_GB_EFO_EPS_OUT_13 <> HR_GB_EFO_EPS_IN_13

HR_GB_EFO_EAS_OUT_13 <> HR_GB_EFO_EAS_IN_13

HR_GB_EFO_EYU_OUT_13 <>HR_GB_EFO_EYU_IN_13

Then I had to create the associated actions:

I will show EAS as an example (and I based this upon RTI):

The send action:

The Receive Action:

You can now log onto the Integration Directory and consume the scenarios as in my first blog

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/06/26/configuring-hmrc-interfaces-for-pi731-aaex

the same steps are followed for the other scenarios until you have created the following:

during the conversations i had with SAP as i trying to get past an annoying P/S/A error from SAP ECC they ensured me new guides would be available for this content soon.  whether the content gets updated, i am unsure, but in the mean time, hopefully someone can find this blog of use.

1.     Document Objective

·         This document provides pre-requisite information about configuration needed for the integration of Non – SAP and SuccessFactors Biz X.

o   Uploading Security Certificates under Trusted CA and Web-Store.

o   Deploying SOAP Axis JAR files on SAP Server to enable AXIS Protocol in SOAP.

·         This document provides an example of the setup in the PI ESR & ID needed for the hybrid integration of SAP ERP HCM and SuccessFactors Biz X.

·         The following information and screen shots have been created based on a test system. Hence, in your case, the configuration will deviate depending on the system landscape and the NW PI release in use.

The document provides a step by step execution of test scenario updating email information from Non SAP system to SFSF Biz X - User Entity.

This process can be replicate to update other fields too.

:

2.     Document Detail

This document explains the setup of scenario for the updating user data consisting of the login and update operation.

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

Third Party to SAP PI integrated through SOAP (HTTP) Sender connector.

SAP PI to SFSF SOAP Login Operation API integrated through SOAP (HTTP) Receiver Connector.

SAP PI to SFSF SOAP Update Operation API integrated through SOAP (axis) Receiver connector.

All calls are synchronous in nature with Third Party being source to SFSF.

The login service needs to be configured differently from all other services.

This is necessary due to the session handling mechanism. While the login service receives the session ID in the payload of the response message, all subsequent requests must use an HTTP header cookie to transfer the session ID to SuccessFactors. Therefore, all services other than the login need to use a communication channel that uses SOAP AXIS adapter in order to write the cookie to the HTTP header.

This procedure can also be copied for other scenarios too.

Target Demo WSDL URL: https://salesdemo4.successfactors.com/sfapi/v1/soap?wsdl

:

:

Technical Solution/ Approach

:

Request Procedure:

Step 1. Non SAP System triggers the process with Update Request Data.i.e. here Non SAP is SOAP UI.

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

Step 3. From Request Message Mapping – SOAP Lookup, Login Operation of SF API will be triggered to get Session ID and get Authentication from SAP Success factor.

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

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

Step 6. This Session ID will be later set in an HTTP Cookie Parameter using Dynamic ASMA properties of Receiver SOAP Channel.

Step 7. Last Update request will be sent to SF using Update Operation and it requires this Session ID to come in HTTP header along with data.

:

Response Procedure:

Step 1 Response will be sent back to SOAP Sender System without any amendments in Message Mapping.

Step 2 Response will be displayed in SOAP UI.

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

Upload the following three security Certificates in exact same sequence under Trusted CA and WebStore.

1. thawte.cert

2. ThawteSSLCA.cert

3. Successfactors.cert                                               

Step to get these security Certificates:-

1.  Go to Google Chrome.

2.  Open SF WSLD URL in Google - Chrome i.e.

< Sales Demo Environment URL: https://salesdemo4.successfactors.com/sfapi/v1/soap?wsdl>

3.  Right Click.

4.  Choose "View Page Info".

5.  Go to Connections.

6.  Choose Certificate information.

7.  Go to Certification Path (Select Path each one by one).

8.  Now go to View Certificates.

9. Above step will open a new window.

10. Go to detail tab.

11. Copy this to file.

12. Repeat steps 8-11 for saving other two certificate files.

     Screenshot: Downloaded Security Certificate

     Screenshot: Before deploying Successfactors Security Certificates – Channel Ping Status.

Steps to Deploy these Security Certificates:-

1. Go to NetWeaver Administrator.

2. Go to the Configuration Management tab.

3. Choose "Certificates and Keys."

4. Select "Trusted CAs".

5. Click the "Import Entry" button.

6. In the "Select Entry Type" field, choose "X.509 Certificate".

7. In the "Enter path to certificate" field type in or navigate to the certificate file you downloaded from the Successfactors URL.

8. Repeat steps 5-7 for the other two certificate files.

9. Highlight Keystore/ WebServiceSecurity.

10. Repeat steps 5-7 for each of the 3 certificate files.

11. Rename Successfactors to *.Successfactors.com.

Implementation of Jar files for SOAP AXIS adapter in SAP PI to enable SOAP AXIS Protocol in SOAP Adapter.

:

Google and Download following JAR files:-

axis.jar

commons-discovery-0.2.jar

commons-logging-1.0.4.jar

commons-net-1.0.0-dev.jar

wsdl4j-1.5.1.jar

1. Note 1039369 - FAQ XI Axis Adapter

2. Download attachment - faq_axis_adapter.ZIP

3. Extract ZIP file.

4. Go to Path "faq_axis_adapter\res\axisprovider\710_minimum_kit\710\minimum_kit\"

5. Open “com.sap.aii.af.axisproviderlib.sda” with winrar

"Note: This is a Template SDA file with Blank JAR files in it"

6. Add above downloaded JAR files in com.sap.aii.af.axisproviderlib.sda\lib folder.

7. Maintain all entries in com.sap.aii.af.axisproviderlib.sda\server\provider.xml

8. Get it deployed on SAP PI Server.

Use URL http ://<host>:< port>/XIAxisAdapter/MessageServlet/ to check whether it is correctly deployed or not.

to be continued.. PI.DOC- Integration between Non-SAP System and SFSF BizX. - Part II

:

Due to Size limitation rest will be continued to PI.DOC– Integration between Non-SAP System and SFSF BizX. - Part II

This document is in continuation to my previous blog PI.DOC- Integration between Non-SAP System and SFSF BizX. - Part I

:

Screenshot below shows Development [ESR] object for Update User Data.

:

PI ESR Object Development Overview

Externel Defination created using Demo WSDL URL: https://salesdemo4.successfactors.com/sfapi/v1/soap?wsdl

1.       Open above URL in explorer.

2.       Right Click

3.       View Source

4.       Save as SF.wsdl

5.       Use this WSDL to create External Defination.

6.       Message SFWebSeviceFaultException is used to handle Fault Message.

7.       Message UpdateResponse is used to handle Response Message.

Name : EXTDEF_SuccessfactorsDemoWSDL

Request Message Type

:

UpdateRequest of WSDL External Defination  is amended and saved again as XSD, which will be used later in Request Message mapping.

Reason of doing changes in updateRequest : It doesn’t have email fields added in it. So in our case we added email field in updateRequest then saved it as .XSD and again uploaded it for further use.

:

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

Name : EXTDEF_UpdateEmailOperation_XSD

Create Outbound and Inbound synchronous service interface.

Name : UpdateRequest_Sync_Out

Name: UpdateRequest_Sync_In

Message Mappings

Message Mapping – Request

Name :UpdateOperation_Request_MessageMapping

UDF Name :Get_SessionID

Purpose : UDF is to perform soap lookup and get session ID as response. Later pass this UDF to next UDF.

UDF Name :Set_Cookie

Purpose : UDF is to use dynamic configurations and communication channel’s ASMA properties to set SessionID as Cookie parameter of HTTP Header.

e.g. Cookie = JSESSIONID=XXXX.XXXX.XXXX.XXXXX

Message Mapping – Response

One to One Mapping.

Name : Update_Response_Mapping

:

:

Message Mapping – Fault

One to One Mapping.

Name : Messagemapping_Fault

Opeartion Mapping :

Name : UpdateOperation_OperationMapping

to be continued.. PI.DOC- Integration between Non-SAP System and SFSF BizX. - Part III

:

Due to Size limitation rest will be continued to PI.DOC– Integration between Non-SAP System and SFSF BizX. - Part III

This document is in continuation to my previous blog PI.DOC- Integration between Non-SAP System and SFSF BizX. - Part II

:

Screenshot below shows Configuration [ Integration Directory] object for update user data scenario.

:

PI Configuration Overview

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

BC_Successfactors_One_D

BC_Successfactors_Two_D

The business component contains sender interfaces and sender connector.

Outbound Interface : UpdateRequest_Sync_Out

Connector Sender : CC_SOAPUISessionCreate

The business component contains receiver interfaces and receiver connector.

Inbound Interface : UpdateRequest_Sync_Out

Connector1 : CC_SOAP_Receive_SessionCreate

Connector 2: CC_SOAP_Axis_Receive_DataSend

SOAP Sender Communication channel– Getting data from source system.

Connector Sender : CC_SOAPUISessionCreate

SOAP Receiver Communication channel– Used to call login Operation to get session ID.

Connector1 : CC_SOAP_Receive_SessionCreate

[  Image ]

SOAP-AXIS Receiver communication channel along with axis Module config:

Sending xml data to SFSF SOAP UpdateOperation API with Session ID in HTTP header.

Connector 2: CC_SOAP_Axis_Receive_DataSend

Integrated configuration Object : Check Screenshot Tab by Tab.

Testing Scenario:

Updating email address to SFSF from third Party.

Updating RJohnson@ACECompany.com with Prabhat.b.sharma@ACECompany.com

1.       Log in into Successfactor frontend

2.       Go to Admin tool

3.       Open API Data dictionary

4.       Search User Entity details.

Downloading WSDL to desktop from SAP PI Integration Directory :

1.       Log in into SAP PI Integration Directory

2.       Open Integrated Configuration Object

3.       Go to Integrated Configuration

4.       Hit Display and generate WSDL.

5.       Result : Downloaded WSDL to Desktop.

Sender System Application: SOAP UI Tool

1.       Upload Downloaded WSDL here in SOAP UI.

2.       Populate Sender data in appropriate fields.

3.       Choose correct endpoint.

4.       Enter SAP PI Username and Password Detail.

5.       Hit Send Response data

6.       Result : Here Sent Response data to SAP PI System and Receive Success response.

Middleware - Message Monitoring :-

1.       Go to SAP PIMON

2.       Choose Message Monitoring

3.       Fill appropriate filter criteria and Shows Message

4.       Result : Here successfully received and delivered to SF SOAP API.

SAP PIMON Message Monitoring log details.

Target System : Successfactor Biz X.

1.       Log in into Successfactor frontend

2.       Go to Admin

3.       Open API Audit Log Details.

4.       Result : Here Shows Request and Response data received from SAP PI.

Successfactor frontend screen showing updated email ID. - Successful.

Thanks ......

Please share comments and review.