Monitering and storing Fault Messages through RFC LookUp

[suchitatomar]

Hi Guys,

This is my first blog on SCN so just sharing one of the functionality which we can use for storing FM messages in database tables.

Hope this can be helpful for beginners. Appreciate your feedback 🙂 in case it was helpful.

Summary

In SAP Net Weaver Process Integration (PI) 7.1, there is now graphical support for RFC mapping lookup in message mappings, instead of creating a user-defined function with the relevant lookup code as in previous releases (e.g. XI 3.0/PI 7.0).

1.   Overview

This Document will explain you RFC mapping lookup in message mappings, instead of having to create a user-defined function This new feature significantly facilitates the creation of such mapping lookup and allows the PI developer to allocate his/her time. The Request is sent through WS call.

Using RFC LOOK-UP, the RFC is called and the response gets generated and the response from the SOA is sent and stored to ABAP Z table (ZPI_FM_ERROR) which can be helpful for monitoring the fault error messages and manual work to every time search message is reduced . Here we have a synchronous scenario

WS  <-------> Soap

RFC Lookup is a small UDF which helps to execute the RFC query to any SAP system and fetch the output the RFC inside the UDF. This method is generally is very helpful when we want to execute RFC method in SAP for further details from SAP based on the data passed to the mapping.

This UDF can be used to connect to any SAP system and execute the RFC statements.

2.   Prerequisites and Requirement

• The RFC channel to be used for the lookup must be configured and activated in the Integration Directory.
• The definition of the RFC structure used for the lookup must already be imported into the ES Repository as an imported archive.

Here we are going to use ZPI_FM_ERROR. The BAPI will take the input as the MessageID, ErrorType, ErrorMessage, ErrorCode, FieldName, InterfaceName, HostSystemId and the data is stored in ABAP table. Create the communication channel for the RFC Receiver. Select the adapter type as RFC. Give the R/3 System details like, Application server name, system number, logon user, password, client, language.

RFC Table

Fields Name	Length	Occurence
messageId	36	1..1
errorType	Possible values	1..1
	ValidationError (V)
	BusinessError (B)
	systemError (S)
errorMessage	1000
ErrorCode	20
fieldName
timestamp		1..1
interfaceName	30
Host systemId	20

RFC Lookup Use case:

• UDF uses the channel (PIRFCLookUp) to access the SAP System
• UDF passes the RFC XML message to the channel
• Channel execute the RFC and returns the results to the UDF.
• UDF can retrieve the output content.

Source Code:

Global UDF Name: getHeaderFields
Input Parameter constant Value: REF_TO_MESSAGE_ID, RECEIVER_NAME
Output: Stores the result from the RFC call to ABAP table

1.Logic to get header fields

• MessageID
• InterfaceName

public String getHeaderFields(String param, Container container) throws StreamTransformationException{

java.util.Map map = container.getTransformationParameters();

String headerField = "";

if (param.equals("REF_TO_MESSAGE_ID"))

headerField = (String) map.get(StreamTransformationConstants.REF_TO_MESSAGE_ID);

else if (param.equals("RECEIVER_NAME"))

headerField = (String) map.get(StreamTransformationConstants.RECEIVER_NAME);

return  headerField;

}

2. Logic to dynamically store sub-string up to 255 characters

public String subString(String input, int start, int length, Container container) throws StreamTransformationException{

//Extracts the substring of an input String

// start - position index for start of string

// length - length of substring

int startPosition = start;

int endPosition = start + length - 1; 

String output = "";

if ( startPosition < 0 )

{

  output = "";

}

else if ( startPosition >= 0 && startPosition < input.length() )

            { 

  if ( endPosition < input.length() )

  { 

  output = input.substring( startPosition , endPosition  + 1 );

   }

  else if ( endPosition >= input.length() )

  { 

  output = input.substring( startPosition , input.length() );

   }

  }

else if ( startPosition  >= input.length() )

{  

  output = ""; 

}

return output;

}

Source Code Reference snap shots:-

Message Mapping

Select the source message and target message type.

A message mapping parameter must be created within the Signature tab. It should be an 'Import' parameter and have Category 'Adapter' and Type 'RFC'. The name of the parameter should be the RFC channel name which we have created in Integration Directory. In our case it is ‘LOOKUP_CHANNEL’.

Steps:-

1. In mapping functions, under conversions, select RFC Lookup.
2. Double click on RFC Lookup. Select the RFC which we have imported. We can see now the request and response message elements.
3. Select and Double click on the request fields and response fields. Then we can get the fields which we have selected in below the RFC structure.

Note:-

Check that the RFC should be in green color and at last there should be input to RFC call and output too (Refer below screen shot) i.e input fields to be mapped to output field.

Operational Mapping

Click on the binding and select the binding parameter as “LOOKUP_CHANNEL” in case the parameter used/passed in the binding of mapping program is above.

To test go to the test tab and then select the value for LOOKUP_CHANNEL

4.  Results:

Test Results stored in ABAP table:-

Note:

Click on binding in the operational mapping so that mapping parameters are assigned to it, else it this will error out if not done, while testing. Also check in interface determination whether the RFC lookup parameters are passed or not.

5.  Bottleneck Issues/Challenges:-

1. Error Message:

MAPPING">RUNTIME_EXCEPTION</SAP:Code> <SAP:P1>Thrown: java.lang.NullPointerException: while trying to invoke the method java.lang.String.length()of a null object loaded from local variable 'guid'at com.sap.guid.GUID.parseHexGUID(GUID.java:104RuntimeException&quot; survenue lors du mappage

         Solution:

This Error  was seen in QA environment, as in interface determination  there are no parameter assigned and it was taking this as a null value since transports for ID were missed, once the transport of interface determination object and communication RFC channel object to QA environment was done, this was resolved .

2. Change in requirement for handling/storing data in ABAP table up to 256 characters only (rest will be truncated) rather than 1000 characters.

Challenges:-

During testing it was found that we cannot pass more than 256 characters to RFC lookup table as it accepts data as String type whose predefined length is 256, so rest all the characters will be truncated.

Possible Solution to fix this requirement:-

Here as the max. Length of data passed via RFC is limited to 256 characters i.e. 0-255, so to resolve the point, we may need to use the Table parameter of the BAPI. Finally, we can map our table parameter in PI with line type TDLINE and write a function in PI that will automatically create a paragraph of text into multiple lines of 132 characters and pass to the BAPI Table parameters which can then be re-combined in SAP.

Regards

S Tomar