Skip to Content
avatar image
Former Member

Communication Channel start and stop using External Control

Hi Experts,

I am facing a different behavior when starting and stopping communication channel in 'Communication Channel Monitor' and using the URL to start and stop the communication channel. (1) From the channel monitor start and stop, the message that is failed is going through whereas (2) Using the external control (url), the message is still in the error status but the channel logs says it is stopped and started. The communication channel is an MDM-Receiver and on SAP PI 7.5 SP07.

Any thoughts on how different is stopping and starting the channels in channel monitor and when using an external control (URL) ?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Jul 18, 2017 at 10:18 PM

    Hi Nikhil,

    There shall be no difference in the functionality you described: PI Adapter Engine's Adapter Framework contains the component (a part of generic Adapter Administration and Monitoring sub-component, which is adapter type agnostic) that is responsible for tracking messages that have been sent to the stopped channel, and when the channel is started again, triggering retry attempt for those accumulated messages. This functionality doesn't depend on the method that was used to stop the channel - using user interface (of Communication Channel Monitor) or exposed services (such as ChannelAdminServlet) - it primarily looks into channel status and checks if it is active or stopped by any means.

    I would suggest having more precise look if that part of functionality worked well or not. To do this, can you please collect two XPI Inspector traces for the service 'XPI Service: AF Service' (it is better to collect to discrete traces so that they can be compared later on):

    1. Stop channel using Communication Channel Monitor, start XPI Inspector trace, send message to a stopped channel, start channel and check in Message Monitor / Communication Channel Monitor that the channel started successfully and message got processed, stop trace.
    2. Stop channel using service / ChannelAdminServlet, all the rest is the same as in the first test.

    In both traces, search for following two calls' sequences:

    1. In the trace for the server node that processed message (the server node ID can be checked from message details in Message Monitor), call of class StoppedChannelMessageManagerImpl, method markMessageForRetry(), with arguments of the method call which are corresponding channel ID (can be checked from object properties of the channel in Integration Directory) and message key (message ID and direction). The call is triggered as soon as the message arrives to the stopped channel and is an indicator of the fact that the channel stopped status was recognized by Adapter Administration and Monitoring component and the message which arrived to the channel was picked up by this component for further automatic retry.
    2. In the trace of the server node that processed the call for channel start (in clustered environment, it may be a different server node to the node that processed message), calls of class AdminManagerImpl, method setChannelActivationStatus() - indicator of successful recognition of successful channel startup, followed by StoppedChannelMessageManagerImpl, method redeliverMessagesForChannel() - indicator of triggering functionality responsible for identification of affected messages that have to be retried, followed by StoppedMessageInfo, method resendMessage() - indicator of triggering retry for the specific affected messages (in method trace entries, there shall be a text saying that the message with the given message key - the one that got delivered to the channel when it was stopped - got scheduled for re-delivery for the channel provided its ID; both message key and channel ID shall be same as evidenced earlier in the point 1). If there were many messages processed and delivered to the stopped channel, this may take some time, since number of threads that can be allocated for messages' retry, is limited - on the other hand, if you can keep test limited to one message, then you shall be able to evidence these calls immediately after call to start channel is processed.

    Please check that you can find these occurrences in both traces - if you find them in one trace, but not in the other other (assuming traces are complete and not corrupted), I would rather consider this is a bug.

    Regards,

    Vadim

    Add comment
    10|10000 characters needed characters exceeded