Online Tutorials & Training Materials | STechies.com
Register Login

Starting and Stopping SAP PI System

|| || 0

Starting and Stopping SAP PI System
Stechies

 

You want to shutdown the PI system and are unsure regarding the correct sequence in which the components should be shut down and then started. The Technical Operational Manual for PI doesn’t really provide enough of information about process of stopping and starting. The procedure explained here makes sure that the system is isolated so that no further message processing occurs. This is very essential especially in situations where the user wants to avoid message processing during a system maintenance or wants to be prepared for a point in time recovery of his database (e.g. for release upgrade, system maintenance or during a hardware switch).

This tutorial here explains the various options for the multiple available PI usage types for isolating a PI system before restarting.

Solution

New with PI 7.31:

Beginning with 7.31 a new possibility of isolating the Adapter Engine was introduced via Document 1884085. The Adapter Engine can now be placed in state where no messages are processed. The suspend and resume operations work on the communication channel level. With a single user action, this permits all the communication channels (CC) to be suspended or resumed. The suspend action puts a stop to the all channels without making any changes the administrative state of the channels which is stored in the Adapter Framework. During the resume operation, the channels are reinstated to the state they had prior to the suspend operation. 

Both the suspend as well as resume actions are triggered by the Java Job Scheduler. The name of the job is SuspendResumeAFWJob, and this has a single parameter which specifies whether the channel should perform a suspend or resume: channelsSuspended. A suspend is performed, incase the parameter is true and incase the parameter is false then a resume is performed. If the Adapter Engine is already in the state which is requested, the job exits without performing anything. For instance, if the user tries to trigger a suspend on an already suspended engine, nothing will happen. If the communication channels have been suspended, then its impossible to start them from the communication channel monitor. The monitor verifies and shows the suspended status of the Adapter Engine. All channels are visible as being stopped.

Before we move on to the detailed description regarding the procedure for the various PI installation options:

1.Advanced Adapter Engine Extended (AEX) or Non-Central Adapter Engine :

1.1 STOP procedure:

1.1.1. Open the /nwa -> Operations -> Job -> Job Scheduler -> Tasks. Add a new task by selecting SuspendResumeAFWJob. Set the parameter channelsSuspended to true. Incase the system is down the Suspend can be initiated from the AS Java Config Tool ->  Configuration Editor -> Configurations navigate to PI_AdapterEngine and set the value of the channelsSuspended to true.

1.1.2. Post execution of the job user checks in the CC Monitoring that all CC are stopped using /pimon -> Monitoring -> Adapter Engine -> Communication Channel Monitoring. Checking the value of the channelsSuspended field in the Configuration Browser doesn’t help here as this only displays the cached value and not the actual value on DB.

1.1.3. Verify that no further message processing is taking place by using /pimon -> Monitoring -> Adapter Engine -> Message Monitor and selecting the Message Status Overview.

No new messages will come into the system any longer.

1.2. START procedure:

1.2.1. Open /nwa -> Operations -> Job -> Job Scheduler -> Tasks. Add a new task by choosing SuspendResumeAFWJob. Set the parameter channelsSuspended to false. All Communication Channels which were initiated prior to the suspend operation will be restarted. Incase the system is down the Resume can be initiated from the AS Java Config Tool ->  Configuration Editor -> Configurations navigate to PI_AdapterEngine and set the value of the channelsSuspended to false.

1.2.2. Verify that all the appropriate channels are running again in the CC monitoring in /pimon -> Monitoring -> Adapter Engine -> Communication Channel Monitoring.

1.2.3. verify that the PI message processing continues as normal using /pimon -> Message Monitor and choosing the Message Status Overview. In case of erroneous messages restart them manually. In case there are too many messages are in error the user can also schedule the restart job using /pimon -> Monitoring -> Adapter Engine -> Background Job Processing Monitor and create a new job using the Job Type "Restart". Before doing this please check the overall number of messages in error in your system (not only the most recent ones), as also old messages will be restarted by the restart job! This can even lead to old data being processed, overhead on the PI system, high DB database used and must be done carefully.

Process Orchestration (PO):

2.1. STOP procedure:

2.1.1. Usually BPM processes sent/receive data via Interfaces through PI Messaging, which will be stopped as per point 1.1. hence no new data is processed. In case BPM processes are triggered by the direct calls (without going through PI Messaging), the sender communications must be stopped.   

2.1.2. Stop the Adapter Engine as described in 1.1.

2.2. START procedure:

2.2.1. Start the Adapter Engine as described in 1.2.
2.2.2. Checking the status of the BPM System in /nwa -> Availability and Performance -> BPM System Overview.

Advanced Adapter Engine Extended or Non-Central Adapter Engine prior to SAP Document 1884085:

The general idea is stopping and starting all sender Communication Channels (CC) manually on the Adapter Engine. A problem may be that you have channels in your system which are already stopped since for instance business does not want to receive the data or you are changing the design of the interface. Post the PI maintenance these stopped sender channels should not be started. Generally, there is no need to stop the receiver channels as post stopping the CC the remaining messages in the system are required should be consumed within a reasonable time.

3.1. STOP procedure:

3.1.1. Note down all CCs which are currently stopped. Note also down all the CC in errors (if any) so that user can verify if a potential problem post starting already existed prior to the stopping of the system.

3.1.2. Stop all sender CC manually in /pimon -> Monitoring -> Adapter Engine -> Communication Channel Monitoring. Use the Advanced search and specify in the filter direction "Sender" and use the "Stop" Button to stop all sender CCs. Use the multiple selection features for doing this.

3.1.3. Monitor the Adapter Engine (AE) until all the messages are processed. If the user wants to avoid temporary errors in message processing user should wait till all the messages have been processed successfully in the AE. Otherwise these messages might fail and maybe required to be restarted during the startup as described below. To monitor the message backlog use the pimon -> Message Monitor and use the Message Status Overview. Verify for all messages in status Scheduled.

3.2. START procedure:

3.2.1. initiate all the CC except the ones which have been stopped before and which the user noted down in 3.1.1.. As before use /pimon -> Adapter Engine -> Communication Channel Monitoring. 

3.2.2. verify in the CC Monitor that all sender channels have a green status after restarting. Incase there are channels in error please check if you have noted them down in 3.1.1

3.2.3. Monitor the Message Processing on the Adapter Engine using /pimon -> Monitoring -> Adapter Engine -> Message Monitor and use the Message Status Overview. Check that all messages have been processed successfully.

Dual-Stack PI:

4.1. STOP procedure:

4.1.1. If you utilize the Business Process Engine (BPE), please follow SAP Document 893218.

4.1.2. Adapter Engine: Stop the CC as described as described in 1.1. (if Document 1884085 is available) or in 3.1. (if Document 1884085 is not available).

4.1.3. ABAP Integration Engine: Stop incoming messages: There are various  ways of stopping the incoming messages. The simplest way is to set the use ENTRY_LOCK parameter by utilizing transaction SXMB_ADM -> Integration Engine Configuration -> Specific Configuration -> Change -> New Entries. Select the category RUNTIME and then the parameter ENTRY LOCK: Set the value to 1 (LOCKED) and select Save. This will avoid that new messages can enter the Integration Engine pipeline (the sender system will get an error). All messages still residing in the qRFC queues (SMQ2) will be processed. For avoiding this follow step 4.1.4.

4.1.4. ABAP Integration Engine: Stop messages processing for avoiding this user can deregister the queues. This can be done by using transaction SXMB_ADM -> Manage Queues. Selecting the radio button "Deregister Queues" and then the button "Execute action". By doing this the processing of all messages in the queues will be immediately stopped.

4.1.5. Check tRFC entries via transaction SM58 until the list is empty.

4.1.6. Stop the PI system.

4.2. START procedure:

4.2.1. If the SLD is functioning on a different host and has been stopped for maintenance reasons, you would be required to start it.

4.2.2. Start the PI system.

4.2.3. Wait until the J2EE Engine and all PI related services are started. This entire process can be monitored via the SAP Management Console using http://server:5<sid>13 port. verify that all server nodes are green and have status visible as "Running".

4.2.4. ABAP Integration Engine: If locked in step 4.1.3 with parameter ENTRY_LOCK open the Integration Server for incoming messages by calling the transaction Integration Engine - Administration (SXMB_ADM) and choosing Integration Engine Configuration -> Specific Configuration. Choose the category RUNTIME and then the parameter ENTRY LOCK: Set the current value to 0 (NOT LOCKED) and choose Save

4.2.5. ABAP Integration Engine: Register the XI queues via transaction SXMB_ADM -> Administration -> Manage Queues. Choose action "Register Queues" and hit the button "Execute action" afterwards. Check the queues via transaction SMQ2 for their status (should be "RUNNING" after some time). 

4.2.6. Adapter Engine: Start the CC as explained in 1.2. (if SAP Document1884085 is available) or in 3.2. (if SAP Document1884085 is not available).

4.2.7. If you utilize the Business Process Engine (BPE), please follow SAP document 893218. 

4.2.8. verify the message status on PI Integration Engine, Java Adapter Engine and connected Proxy systems: 

For doing so use the PI Runtime Workbench /rwb and restart messages in error: 

  • RWB -> Message-Monitoring -> Adapter Engine <host> and
  • RWB -> Message-Monitoring -> Integration Server and
  • RWB -> Message-Monitoring -> Proxy Runtime <business_system> (in case the connection to the Proxy systems are configured).

Incase there are many messages in error user can use the automatic restart job of the AE: RWB -> Component Monitoring -> Adapter Engine <host> ->"Background Processing".

4.2.9. Check Integration Processes (if used) via transaction SXMB_MONI_BPE -> "Restart Process After System Crash".

4.2.10. Check for errors on all the sending systems for e.g. failing IDocs in SM58 or failing Proxy messages using SMQ2 or SXI_MONITOR on the sender system and then restart them as appropriate.

 


Related Articles

0.0135 seconds.