SAP NW Newbie

As we all know, the PI objects are created or edited using the Integration Builder tools. The development area is isolated from runtime area in PI. Changing or creating objects does not change or create them directly in runtime. Runtimes have their own database for storing the PI objects. Only the latest, active versions of the objects are available in runtime. When the PI objects are changed in IB, the changes are written as an xml message and sent to the runtime components  (ABAP Integration Server, Java Adapter Engine CPA cache, Java Message Mapping Cache and Java Value Mapping Cache). The runtime components read this message and make the adjustment to their versions of XI objects to keep the objects in sync with the recent changes. If for some reason the cache updates triggered by changes in IB fail, one can trigger a delta cache or a full cache refresh to keep the objects consistent using the URL  http://<pi-host>:<pi-j2ee-port>/CPACache/refres...

If you see that a JDBC sender channel is not polling after a java node crash , check the locks. When a JDBC sender channel polls, it sets a lock in the enqueue service (SCS instance). With a crash, these locks will be left hanging and the channel will not poll until the lock is removed. To get the channel to poll again , follow this process: 1. Stop the channel 2. Go to Visual Admin --> Locking Adapter --> Display locks tab and refesh the locks view. 3. Select the existing (hanging) enqueue lock with JDBC (The lock has $XIDBAD.JDBC2XI and channel ID in tis name. The channel ID can be determined from <Path to server node>/log/services/com.sap.aii.adapter.jdbc.svc) 4. Delete the lock. 5. Start the channel The problem can be avoided by setting 'taskTimeout' parameter in the channel. When the channel sets a lock, it passes the value of this parameter to the enqueue service and the enqueue service will not hold this lock longer than this time. If the c...

If you are sure that the user name and password are correct and the behaviour is different from what is explained in our older post  Message Fails With 401 Error; Gets Processed On Second Attempt , see if the Communication Channel connects to a Windows OS based Web Service with a domain user.  If so, you should be using <Domain_Name>\ <User_Name > in the CC configuration.

XI messages fail when there are unplanned J2EE server node restarts. You can reduce the number of such failed messages by delaying the start up of JCo RFC provider to start after the applications are up. WaitForAppsStart property has to be set on JCo RFC Provider service to use this feature. You can change this proprty using Config Tool --> services --> rfcengine. You may have to create the property if it is not already existing and set it to true. Check SAP Note 1444430 to confirm if this property is supported at the SP level you are running the XI application on. The HTTP service is delayed automatically to start after the node is at Running status for releases 7.1 and above. If you are using a release lower than 7.1, you can configure the delay manually with the property DelayedServerNodeRegistration of the HTTP Provider Service on the Dispatcher. Be aware that delaying HTTP service may cause SLD registration problems, which need to be dealt with manually. ...

SAP Note 967812 lists the mandatory Services and Application required on XI. The same are listed here. Dispatcher/Server Service Name (Visual Admin) Service Name (Configtool) Mandatory? Impacts if the service is disabled? d/s ABAP Communicator r3startup mandatory for XI d/s Administration Adapter adminadapter mandatory for J2EE s Application Client appclient not mandatory CTS will fail s Application Locking applocking mandatory for XI d/s Basic Administration basicadmin mandatory for J2EE d/s Classloader viewer classload mandatory for XI s Classpath resolver classpath_resolver mandatory for XI d/s Configuration Adapter configuration mandatory for J2EE s Connector Container connector mandatory for J2EE s Deploy deploy mandatory for J2EE s Destinations tc~sec~destinations~service mandatory for XI s Distributed Statistics dsr not mandatory No J2EE statistical data will be gathered. s EJB Container ejb mandatory for XI s File Service file mandatory for J2EE d/s HTTP Pr...

JARM collects response time of application which may be helpful in troubleshooting performance problems to improve user experience. However JARM itself causes performance overhead for data collection . It may be turned on for troubleshooting and kept off during normal use by performing the following steps: 1. Logon the j2ee engine via Visual Administrator. 2. Go to server_XXX -> services -> Performance Tracing. 3. Select the properties tab 4. Change value of property jarm/switch from on to off, then press update and save for all nodes.

If you have restrictions on the maximum heap memory that can be allocated for J2EE engine, chances of OOM error can be reduced by reducing maximum message size and messages/mappings that can be processed in parallel. Following are few suggestions: 1. Reduce the number of parallel mappings. Reduce "Number of Connections" for the destination AI_RUNTIME_JCOSERVER in JCo RFC Provider service. This will reduce the maximum number of simultaneous mapping requests that can be made, reducing memory consumption. 2. Reduce the number of threads allocated for each adapter. By reducing the number of threads allocated for each adapter, the number of messages that are processed in parallel can be reduced. You can control the thread allocation for each adapter by customizing messaging.connectionDefinition property in the service SAP XI AF Core.   Check http://sapnwnewbie.blogspot.com/2010/10/threads-per-adapter-type-and-receiver.html 3. Reduce the time interval within which the ...

You can increase the scalability at Adapter and Channel level with these two options: Maximum Threads per Adapter Type: You can control the thread allocation for each adapter by customizing messaging.connectionDefinition property in the service SAP XI AF Core using the following syntax: messaging.connectionDefinition=(name=global,...)(name=<AdapterTypeIdentifier>, Send.maxConsumers=<a>, Recv.maxConsumers=<b>, Call.maxConsumers=<c>, Rqst.maxConsumers=<d>) with <AdapterTypeIdentifier>=<AdapterType>_<Namespace> (e.g.: File_http://sap.com/xi/XI/System) Send.MaxConsumers indicates queue for asynchronous communication from AFW to IS Recv.MaxConsumers indicates queue for asynchronous communication from AFW asynchronous Call.MaxConsumers indicates queue for synchronous communication from AFW to IS Rqst.MaxConsumers indicates queue for synchronous communication from IS to AFW synchronous Check SAP Notes 1084161 and 1129604 for mo...

Channel monitoring is pretty straight forward. Traffic lights indicate if the Channels are functioning properly. There are some known exceptions: 1. You are sure that the SOAP channel is configured correctly and it is active. But the RWB shows the Channel traffic light Grey The channel will show grey until the first message is passed. This is a normal behaviour for SOAP and Mail adapters 2. Channel is in Red status even after you have eliminated the cause of error Again this is normal behaviour. The status shows Red until messages are processed. In a cluster environment, you may notice that one of the nodes is green and is processing all the messages and the other node(s) show errors. This is because the other node(s) did not process a message yet.

SAP has released a patch to fix a problem with the SOAP Adapter Message Servlet. When a (SOAP) Sender posts a message, the SOAP Adapter Message Servlet, responsible for handling the message would be processed by a thread. if these messages are sent during a high load, there are chances that they are sent for processing on a thread already engaged in a transaction. In such cases the messages are simply lost as neither a soap fault was sent nor the message was persisted. The fix will cause a soap fault being sent when the SOAP Adapter Message Servlet already in a transaction. Check SAP Note 1491483 - SOAP Adapter - Messages lost under high load f or more details.

You can trace the AFW jobs on these locations: com.sap.aii.af.[service|lib].scheduler

Number of Messages by Status: select status, count(1) as current_number from sap[sid]db.xi_af_msg group by status; STATUS CURRENT_NUMBER ------------ -------------- DLNG 20 DLVD 460529 FAIL 19 NDLV 17 TBDL 64 Messages With a Particular Status (ex: NDLV): select count(1) from sap[sid]db.xi_af_msg where status like 'NDLV'; COUNT(1) ---------- 17 Messages Processed after a Certain Time: select * from sap[sid]db.xi_af_msg where sent_recv_time > [time] and node = [node id]; These tables don't seem to exist in PI 7.1 with the same name Edit: BC_MSG is the table name in PI 7.1. Thanks to JustMe for providing the table name.

Message Flow from Adapter Engine to Integration Server (Ex: File Sender): Message Processing within Integration Server: Message Flow from Integration Server to Adapter Engine (Ex: JDBC Receiver):

If you observe high response time, while the CPU utilisation remains low, then check the socket time out settings. High socket time out on a fast machine would cause high number of http requests loaded. Most of the CPU time would be spent waiting to read data from an inactive client than processing requests for an active client. Reduce the socket time-out values in Connection Manipulator properties of the dispatcher.