Transporting Alert Rules in SAP PI 7.31

Alert rules are objects in the Integration Directory. Similarly to the other PI configuration objects, an alert rule can be transported from the originating Integration Directory to other Integration Directory systems in different system landscapes.

Transporting Rules

The process of transporting an alert rule consists of the following steps:

  1. The user transports an alert rule from a source to a target system.
  2. The target system creates an alert rule with exactly the same name and parameters and automatically puts it into an open change list (named PI 7.1 Import).
  3. After the successful import, the user has to activate this change list.
  4. During change list activation the system runs the consistency check procedure for the alert rules. One of the following can happen as a result of the check:
  • The system reports possible inconsistencies of the imported alert rules contained in the change list. If a rule has become inconsistent during transport (for example, an assigned runtime component is not valid in the target system) the change list cannot be activated. The user has to manually correct the corresponding rule in the target system as described below, and then activate the change list again.
  • In case the alert rule is consistent, the system activates it.

Changes in Alert Rule Parameters

Most of the parameters of an alert rule are also valid in the target system without any restrictions. Therefore, they can be transported without any automatic or manual adjustments in the target system. The following parameters are transported with no adjustments necessary:

Name, Description, Severity, State, PayloadInAlert, Status Details, and Consumers.

The alert rule object may contain parameters that are only valid in the current landscape and may need automatic or manual adjustment in the target system. The following parameters might need to be adjusted after transporting them:

  • Links to configuration objects that contain Business system names.
  • Business systems explicitly selected in the runtime components.
  • Decentral adapter engines explicitly selected in the runtime components.

The sections below provide information about what you can do to correct the transported alert rules.

Correcting Configuration Object Links

In general, configuration object links that contain business system names are not valid in the target system, since business system (names) are different in the source and target XI domain. The configuration objects that can be linked to an alert rule and are affected by this are: Business Component (of type Business system), Sender Agreement, Receiver Agreement, and Integrated Configuration.

During import (post-processing) of an alert rule that features such links in a target system, the corresponding business system names are switched to the valid ones in the target system by evaluating the business system mapping maintained in the SLD of the target directory. You should consider the following:

  • If, for the business system name, no mapping to a target business system name is maintained, the transport would fail with an exception (TransportPostProcessingException).
  • It is not necessary that the configuration objects belonging to the links are contained in the same transport as the corresponding alert rule, or that these configuration objects are already transported to the target directory. If this is not the case, the consistency check of the alert rule would report warnings naming the missing configuration objects.

Correcting Assigned Runtime Components

Default Case

By default, an alert rule is valid for all admissible runtime components in the source PI domain. After transport, the alert rule would be valid for all admissible runtime components in the target PI domain.

Explicitly Selected Runtime Components

If the user has explicitly selected a subset of the admissible runtime components, then these runtime components are persisted in the runtime components parameter and transported to the target Integration Directory. Depending on the type of the selected runtime components, you can do the following:

  1. Central runtime components (Integration Server, central Advanced Adapter Engine) – After transport, the alert rule would be valid for all admissible central runtime components in the target PI domain. There is no need to make adjustments for such components after transporting the alert rule. Note that if the source directory is in XPI installation mode and the target directory is in AEX (which should not occur), the logical identifier for the Integration Server is removed in the target system if the Integration Server was contained in the runtime components parameter.
  2. ABAP business systems that are explicitly assigned to an alert rule are switched to a new name in the target directory according to the business system mapping maintained in the SLD of the target directory. Consider the following:
  • If, for the business system name, no mapping to a target business system name is maintained, the transport would fail with an exception (TransportPostProcessingException).
  • Besides the fact that a business system mapping must be maintained in the SLD of the target Integration Directory, the target business system must exist as a business component configuration object in this Integration Directory. For enhancement package 1 for SAP NetWeaver 7.3 and later releases, you need to configure the distribution of configuration data in the back-end system for the corresponding business component configuration object. For earlier releases it is not necessary to perform this procedure.

Correcting De-central Adapter Engines

Decentral adapter engines that are explicitly assigned to an alert rule are transported without any (automatic) adjustment to the target Integration Directory. Since the names of these adapter engines would not be valid in the target PI domain, the consistency check of the imported alert rule would report errors. The user must manually deselect these adapter engines and select the valid ones instead. In summary, manual adjustment for decentral adapter engines is always necessary.

Leave a Reply

Your email address will not be published. Required fields are marked *