Skip to Content
Author's profile photo Former Member

No More Hassles with DLNG Status of Message from PI 7.3

Most of the People are already aware that the SAP is planning to release the new version of the Process Integration i.e 7.3 .Looks like SAP have collected lot of business criticality factors and implemented the same in 7.3 which will definitely help the business to trust more and move ahead with PI as strategic middleware of their landscape.

In this blog I want to highlight the backlog feature which can move the status of the message from the DLNG status to the backlog status upon restart of the server automatically.

I request to brush up your skill on receiver adapter threads concept before moving further of this blog.

I will narrate the few cases when the message status goes into DLNG. have established a successful connection to the target business systems (for example it can be either File system using File adapter or Database system using JDBC adapter). Connected business systems went down due to the unexpected maintenance during the message processing.

2.Due to the unexpected huge volume of the Payload.

As a result of the above cases, Status of the message in the messaging system will go into DLNG Status.

Following will be consequences due to the DLNG Status of the message.

     i. DLNG status message thread of the adapter will not be released back to available thread Pool.

     ii.If multiple messages goes into DLNG status of a particular adapter, It will occupy the available threads and in turn will cause the other messages to ToBeDelivered Status.  

     iii.Due to lack of threads available for processing, other messages though does not belong to the blocked interfaces will not be processed.

     iv. performance of the system can be degraded due to the hold of system resources (though depends on other factors also..)

Above all leads to the system restarts.

What to be done even If the restart does not change the DLNG status of all the messages? 

Here we have the new feature incorporated/available from 7.3 onwards.These kind of messages will go into Message BlackList upon restart of the PI box, if still requires the system restart then these messages will be moved into the Cancelled status.(Not Delivered Status NDLV)



Later these kind of messages can be monitored and root cause analysis can be done .Montoring can be done using Message Monitoring with the filter type BackListed.



This feature will definitely help in reducing the number of system restarts.

Note : To avoid multiple instances of same adapter occupying available threads of a particular adapter,we can make use of Maximum Concurrency parameter,but it still does not release problematic threads back to pool,we have to explicitly handle problematic threads.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      The features which you have higlighted is indeed promising but incases were the number of messages with DLNG status are huge and the second restart leads to cancellation , then it would be definately be clumsy to deliver these cancelled messages to the targer Bussiness System ??


      Author's profile photo Former Member
      Former Member
      Blog Post Author

      You can monitor the backlog messages and can trouble shoot the root cause behind the failure and can take appropriate action,which will help to avoid the failures of the other priortiy messages processing in PI..this will lead the business in undisruption mode..