PI outage - stop communication channels?

[Former Member]

Hello,

I had a question from a PI application support standpoint and wanted get some tips on how everyone is handling similar scenario at other clients. We have 600+ communication channels with all different types of statuses (manual, automatic with a schedule, external control on). When multiple components on the server are upgraded like OS, Java, SPS - PI has multiple reboots. Do I need to be concerned about data loss and stop all channels prior to the outage? This is a tedious task which would take atleast a couple of hours after the outage to bring the channels back to their orginal status. Under normal circumstances data that failed in PI should stay in PI which can be later resent (async messages). But would it be possible that since PI is coming up and down multiple times, data might not get committed in PI database leading to inconsistent status of the data (leading to data loss since it cant be resent)?

Any pointers would be helpful to understand how other experts are handling regular PI outages.

Thanks.

[Former Member · Accepted solution]

Hi Jignesh,

In one of our clients, we are stopping some channels before the outage. So we have a masterlist of the channels including the control (automatic/manual) for each channel. It is safer to stop the channels to ensure that data will not be lost during the outage. If you have File sender channels, it is okay not to stop them before outage because it will pick-up the files automatically once PI is back online.

I suggest you check first with your client/s regarding interfaces that are critical in their business, so you will be able to identify the channels that should be checked before the outage and ensure that they are processed completely before the system goes down or ensure that they are processed after the outage especially if the schedule of the channel falls during the outage period. You must coordinate with them regarding the outage so they also know what to expect and they could anticipate the delay of the data/files they need. Also, you need to identify the interface runs which could not be restarted so you can stop the sender channel for those interfaces. For the receiver channels, you do not need to stop them before the outage.

I hope this helps.

Regards,

Jenny

[RaghuVamseedhar]

Hi Jignesh,

You need to stop all sender channels (recommend by SAP) before stopping SAP PI server. Please check this [Link|http://help.sap.com/saphelp_nwpi71/helpdata/en/12/5dd23aaad7b3408dde3c1577fda5b3/frameset.htm].

As Jenny suggested, prepare an excel sheet of all sender channels with details like u201Cmanual, automatic with a schedule, external control onu201D. Stop all channels. When starting, sort by protocol in excel sheet, and restore channel to previous status. I think you can finish in less than half-an-hour.

Regards,

Raghu_Vamsee

[Former Member]

Thanks everyone for your input. Stopping only the sender channels would reduce the effort in half. But I wonder if its a nice to have or need to have. Also I will check the feasibility of taking the server off the network for the duration of outage.

@ Raghu, the link you gave was helpful. However, SAP's recommendation is to stop the IE and AE connections only in situations where there is a chance of restoring the database to a previous instance in which case the data failing in PI during the outage time would be lost. It doesn't specifically hint towards a data loss owing to message not getting committed to the PI database in plain stop and start situations. Or does it?

[Former Member]

worth to read:

https://service.sap.com/sap/support/notes/870864

Note 870864 - Starting and Stopping an XI 3.0 / PI 7.0 System

[Former Member]

Hi.

I have been in the same situation but handling the system downtime in a proper way. We have around 780 communication channels.

Stopping/starting the sender communication channels would still take lot of your time and you could expect some minor issues as well. So i suggest to lock the integration engine before the downtime so that messages won't reach IE from AE. Message would fail in AE with error message saying IE locked and cannot send messages. Once the system is back, you could revert this parameter back and resend the failed messages from RWB.

This also block the incoming messages from ABAP proxies and through sender HTTP.

Next point is , please stop the BPE before the downtime and deregister alll queues using SMQR.

By doing all these activities, you potentailly stop the message processing in PI.

[Former Member]

Hello Jignesh,

In case of outage you need to more concerned of the following:

1. Take care of Sender Communication channels at most. Because these are the ones which actually triggers the message exchanges

2. You should also make sure that during outage there is no outbound happening from any other SAP System

3. If you are taking the outage keeping PI server out of network then you not to be concerned much

4. It also depends on the criticality of the interfaces

Do I need to be concerned about data loss and stop all channels prior to the outage?

You can take care of channels which initiates the communications like Sender communication channels

regards

Ramesh