Blog Archive

Monday, August 6, 2012

XI Production error due to service patch difference in Quality and production.

Problem: code executes properly in production and but not in quality  systems.
Solution: end of the page.


Because of some reasons, Our production maintains low service patch than Quality.

By using java code in mapping, We are trying to get run time parameters of XI system.

this runtime behavior is different with different service patch of Quality and production.  Initially we have done lot of analysis to find the reason.

Before mapping in Quality/production

After mapping in Quality(mapping executed at runtime)

After mapping in Production.( mapping executed at runtime)

Jave code used in message mapping( UDF)

Using UDF in message mapping.

Runtime values of soap envlope in Quality and production

Service patch difference in Quality and Production.

SAP solutions on this.

SAP note number: 1552537

Solution: For testing purpose, we have modified java code in quality. but not transported this change into production.

Planned to move this change , when ever service patch upgrade in production.

;-)  P. Deviprasad.

Reasons for failing messages in XI production, but not in Quality

reasons for failing messages in XI production, but not in Quality

Even though testing is performed well in quality, but we are seeing some failed messages in Production.

New interface/Project
1. are you sending data same manner in Production. what you followed in Quality

When ever errors occurs, see the errors details, this helps us to solve 60-70% of the problem.

Sequence of analysis(if first time in production)
1. First , check if it is due to connection errors?
2. Second, check if it is due to application error?

if it is already running interface
1. first, check if it is due to application errors?
2. second, check if it is due to connection error?

some times, priorty based on our own analysis.

Data errors/ application errors.
ex: 1. same message strucuture in production.
    2. Field lengths.
    3. Mandatory parameters.

Connection errors/access errors( most of the cases)
ex:  1. is support team aware on user exipre details of SAP user id,(i.e connected to XI and vise versa), right roles what quality has
     2. will support team aware user lock information by seeing any produciton error.
     3. support team aware on user exipre details of 3rd party system(that is used communication channels of xi, target urls, are they maintained in same manner(quality) in production. except server host and port any context difference. and also user lock information by seeing any error, 3rd party server status by seeing any error.
     4. support team aware on outages details of SAP and NON-sap Systems.( programmed, un-programmed)
     5. are xi transports properly gone to production.
     6. and also SAP transports and/or 3rd party system transports trasfered properly, if any.
     7. any dependency on XI transports and SAP transport, (which one is first?)
     8. any service patch difference in Quality and production.(some time same code in quality and production behaves differently).

Enhanced projects
     1.if any xi mapping changes(structure changes sender/receiver side), better refresh the production communication channels of xi;
     2.Production team, aware on new changes on that interface. so executing jobs/trigger message based on new condition.

;-) P. Deviprasad.

Testing Enhanced Interface determination scenarios

Configuration test is possible for Interface Determination Scenario.

No. it is not possible,


Message mapping:

Interface mapping
 Receiver determination( multiple receivers)

Now testing this scenario, in configuration .

Note: for testing purpose we use sample data from message mapping, while taking data from message mapping, remember remover additional tags for the test message



But we can not proceed further ,

Reason is,

Then , how to test,

simple: in Development system, Quality,

Use rwb, took. place the test message on the integration engine. before that stop receiver communication channels, so our messages are being failed at adapter engine. then simply cancel those message at adapter engine.

Thus we can do some partial end-to-end testing