SAP Process Integration(PI) Monitoring

In SAP NetWeaver Process Integration(PI),we have two different types of approaches for monitoring the various Integration processes.

• Monitoring of an individual PI domain

Monitoring an individual PI installation can be done using the Runtime Workbench.

The Runtime Workbench runs on the Integration Server, but it also allows the monitoring of distributed PI components, such as local Advanced Adapter Engines or proxy runtimes from SAP business systems.

Start the Runtime Workbench from the PI start page of your Integration Server under Configuration and Monitoring → Runtime Workbench or using the url (http://<host>:<port>/dir).

• Monitoring of multiple PI domains

For the monitoring of multiple PI installations, use the PI monitoring in the SAP NetWeaver Administrator.

Start SAP NetWeaver Administrator for PI from the PI start page of your Integration Server (http://<host>:<port>/dir) under Configuration and Monitoring →NetWeaver Administrator.

Different types of Monitoring offered are :

1. Component Monitoring
2. Message Monitoring
3. End to End Monitoring and Configuration
4. Performance Monitoring
5. Index Administration
6. Alert Configuration and Alert Inbox
7. Cache Monitoring

Component Monitoring

Purpose

 Component monitoring is used in the following cases:

• To get an overview of the status of the individual PI components.
• To call the configuration data of individual components.
• To use test messages to check whether the runtime components are functioning correctly.
• To test whether cache connectivity is functioning correctly.
• To archive the Message Security Settings or Whole Messages
• To check the status of your communication channels or the Java Proxy Runtime configured in them.
• To display current technical data  for your Adapter Engine.
• If you want to prioritize message processing on your Adapter Engine.

The Runtime Workbench is the central tool for component monitoring and provides you with an overview of the current system landscape. To create this view, component monitoring uses data from the System Landscape Directory, the exchange profile, and from the components themselves.

Process Flow

We use the Runtime Workbench to display and monitor the following components:

• Integration Server including the 

1. Integration Engine (central)
2. Business Process Engine
3. Mapping Runtime
4. Adapter Engine (central)

• ABAP proxy systems (business systems with an Integration Engine)
• Non-central Adapter Engines
• Java SE Adapter
• System Landscape Directory
• Integration Directory
• Enterprise Services Repository
• The Runtime Workbench itself

We can also run component monitoring with a special CCMS Alert Monitor for PI. We call this either by choosing CCMS or transaction code S_B6A_52000011. The CCMS Monitor returns an alert status in component monitoring for every component.

This status is based on information from the SAP Computing Center Management System (CCMS). It is displayed by means of an icon, which can be red, yellow, green, or gray.

NB : If the CCMS Monitor for PI is not active, all the components are displayed with a gray (undefined) status. The same applies to components that are not monitored by the CCMS Monitor at all.

You can use the CCMS status to limit the number of components that are displayed. This means that the system only displays those components with the selected status (all, red, red and yellow).

Component monitoring provides two views for displaying the components. When you choose Display, the default view is the table view. This view displays all the components maintained in the System Landscape Directory, their current CCMS status, and the name and type of the component.

NB : The system can only display those components that are correctly maintained in the System Landscape Directory. 

To switch to the tree view, choose Display as Tree. This view sorts the components by component type.

You can select a component from those displayed and do the following:

• Call information on the current status of the component
• Call information about the configuration of the component

You can also do the following, irrespective of which component is selected:

• Check runtime functions
• Check that cache connectivity is functioning

Message Monitoring

Purpose

You use message monitoring in the following cases:

• To track the status of messages
• To find errors that have occurred and establish what caused them

The central message-monitoring tool is the Runtime Workbench. You can also run message monitoring by using Integration Engine monitoring, which you can call from your SAP Easy Access user menu.

In message monitoring for adapter engines, you can restrict access to the message payload for certain types of messages. To do this, you have to create your own actions and group them into roles. For more information, see SAP Note 1370334.

Prerequisites

You have started the Runtime Workbench and have chosen Message Monitoring on the initial screen.

Process Flow

Message monitoring enables you to use the following functions:

• Display and manage messages
• Displaying the Message Overview
• Searching for messages using an index.
• Filter the displayed messages by specific criteria
• Configure the message display
• Edit messages.  

End to End Monitoring and Configuration

Purpose

You use end-to-end monitoring in the following cases:

• If you want to monitor message processing steps in a number of SAP components (to be configured).
• If you want to monitor the path of individual messages through these SAP components, from start to end.

The central end-to-end monitoring tool is the Runtime Workbench. The data for end-to-end monitoring comes from the Process Monitoring Infrastructure (PMI), which is an SAP monitoring tool for monitoring end-to-end technical processes involving multiple SAP components.

Prerequisites

• You have started the Runtime Workbench.
• You have activated the HTTP services required for PMI by calling transaction SICF or program RSXMB_ACTIVATE_ICF_SERVICES.

Process Flow

If you want to run end-to-end monitoring, proceed as follows:

1. Select and configure the components that are relevant for monitoring.
   NB : All components involved must have the logon group PUBLIC.
2. Send the messages whose processing you want to monitor from start to end.
3. Choose End-to-End Monitoring on the initial screen of the Runtime Workbench.
4. If required, enter filter criteria for the sender and receiver.
   Defined selection filters can be saved and reused. Saved filters can also be deleted.
5. Choose Display.

Result

End-to-end monitoring has two views for displaying the data delivered from PMI for the individual processing steps (technical process steps) of the messages in the configured components:

• The process overview
  The process overview displays the total number of processed messages and the number of messages with errors for each component involved. If the number of messages with errors is greater than zero, the status of the component changes from green to red.
  The process overview is the initial screen of process monitoring and contains a graphical representation of the components involved in the process. You can open these components and display the process steps involved.
• The instance view

The instance view displays the path of a specific message through the components involved. Detailed data is available for each individual processing step in every instance.

The instance view contains a graphical representation of all components involved in the process. It displays the status for each of the components that the instance passes through. You can open the components to display a view of the process steps involved with the corresponding data.

If you choose Further Settings in the left screen area, a window appears containing further information and administrative options for PMI. Among other things you can turn the monitoring on and off here, or immediately update the monitoring data that is displayed. To do this, choose Start Now on the General tab page.

For more information about the integration of PMI into the Runtime Workbench, see Displaying and Managing Process Monitoring. You can also access this information by choosing Help on the left-hand side of the screen.

Selecting and configuring components

Use

You select and configure components for the following reasons:

• As a prerequisite for end-to-end monitoring.
• If you want to use the Process Monitoring Infrastructure (PMI) to compile runtime data and display it in performance monitoring.

The configuration takes place in the Runtime Workbench

Prerequisites

• The monitoring server must be maintained correctly in the exchange profile.
• The components to be selected must be maintained correctly in the System Landscape Directory.
  NB : You can select and configure SAP components only.
• Each component requires the user PIRWBUSER.

Procedure

1. On the Runtime Workbench start page, choose Configuration.
2. Enter the logon data for the monitoring server.
   NB : This step is not necessary if you have set up Single Sign-On for your user.
3. Choose Display.The system displays the components of your current domain. The Integration Server is selected as the default.
4. Select the other components that you want to use and configure them as sender or receiver, or both, depending on the component type.
5. Select the monitoring level that you want to use for each of the selected components.The monitoring level determines which tracking agents are activated for the respective component and which monitoring data an active agent delivers.
6. If the component is a logical ALE system, you must make the following additional settings:

• If you want to define the logical ALE system as the sender, choose a sender port from the corresponding drop down list box, from which the messages will be sent to the Integration Server.The Select More Ports action appears. If you want to select additional sender ports from another table, choose this action.
• If you want to define the logical ALE system as the receiver, choose a receiver port from the corresponding drop down list box, to which the messages will be sent from the Integration Server.
  NB : To be able to select ALE ports, they must have been already defined. More information: Defining Ports

     7.Choose Save Configuration.

 Monitoring is automatically activated when you save the configuration.

 NB : Saving deletes the old configuration and the corresponding monitoring data.

     8.If you want to deactivate monitoring, choose Deactivate Monitoring.

Performance Monitoring

Purpose

You use performance monitoring to display statistical data on the performance of message processing. The data comes from the Integration Server (IS) or the Process Monitoring Infrastructure (PMI).

The central performance monitoring tool is the Runtime Workbench.

Prerequisites

• You have configured the necessary data collection from the Integration Server and from PMI for performance monitoring.
• You have started the Runtime Workbench and have chosen Performance Monitoring on the initial screen.

Process Flow

Use performance monitoring to display the following data:

• Aggregated overview data for message processing
• Individual overview data for message processing
• Aggregated detailed data for message processing performance
• Individual detailed data for message processing performance

Use selection criteria to restrict the data that is displayed. For example, you can restrict the data to:

• The data source
• A specific component
• A message processing mode
• A specific time interval

NB : The system only displays messages that are processed successfully within the specified time interval.

You can also choose Extended Search to restrict the displayed messages by using sender and receiver criteria. Selection filters defined in this way can be saved and reused. Saved filters can also be deleted.

• The overview data offers you a quick insight into the number of messages, for example, that were processed in a specific time period for a specific interface, or for a specific combination of sender/interface and receiver/interface.
• If you want to display detailed data, you must specify a unique sender and unique receiver.

NB : Empty input fields are not interpreted as "empty", but as "all". To define an attribute explicitly as “empty”, you must select the corresponding entry (<empty>) from the input help.If you enter <empty> manually, this is not interpreted as an explicitly empty attribute, but as an attribute with the value <empty>.

• If you want to display aggregated data, you must specify an aggregation interval.

Index Administration

Purpose

You use the index administration to control and monitor the indexing for the index-based message search.

Prerequisites

The following prerequisites must be fulfilled before you can use the index administration:

• You have set up the communication between your components (Integration Engines and Adapter Engines) and the TREX server.
• You have started the Runtime Workbench and have chosen Index Administration on the initial screen.
• You have the authorizations of role SAP_XI_ADMINISTRATOR.

Process Flow

To manage your indexes, you proceed as follows:

• You administer the indexing for all components that can communicate with the TREX server.
• You specify global parameters that are valid for all components and that are passed to the components when indexing is active.
• You manage filters, which you use to restrict the indexing of messages according to the defined selection criteria.

Administration of Indexing

To work with indexing administration, choose the Index Administration tab page (default setting). The system displays a table listing all the Integration Engines and Adapter Engines maintained in the System Landscape Directory (SLD).

NB : You can index all components that are based on SAP NetWeaver '04 Support Package Stack 15           or higher, or SAP NetWeaver 7.0 Support Package Stack 06 or higher, or SAP NetWeaver 7.1.

The table also provides the following information:

• Status of indexing:
•  Green (): Indexing is active and has no errors
• Yellow (): Indexing is active; warnings exist
• Red (): Indexing is active; errors exist
• Grey (): Indexing is not active
• Red with lightening (): Status is not known; communication with component is not possible
• Component name
• Type of indexing

The type of indexing selected (standard or fast) is displayed.

• Date and time of the last indexing
• Number of messages available in index
• Date, time, and initiator of last change

Depending on the status of the selected component, you can perform the following activities:

• Choose Refresh to refresh the data displayed.
• Select a component and then select:
• Log, to display the log file for the indexing of the selected component.The log is displayed beneath the table and contains detailed information that may be useful if errors occur.
• A return value of -1 indicates that an exception was raised. The exception text is displayed.
• A return value of 0 indicates that no errors have occurred.
• A return value greater than 0 is an error code from TREX. For more information, see SAP Note 898404.
• Details, to display more information about the errors that have occurred for components with a red error status ().
• Type of indexing
  If you select fast instead of standard indexing, certain analysis steps are skipped, which speeds up indexing considerably.

                NB: The fast indexing method does not support texts in non-segmented                                     languages (Japanese, for example). If you use the fast method for these                           languages, this can cause unforeseen problems. 

• Activate, to activate the set indexing and create an index for the selected component.
• Deactivate, to deactivate the set indexing and delete the index for the selected component.
• A date in the Delta Indexing From field; a delta indexing is to be performed for the selected component for the time period starting from this date up to the current date.
• Start, to start the delta indexing from the selected date.

Global Settings

The global settings are on the Global Settings tab page. Global parameters are parameters that are valid for all components. They are passed to the relevant components when indexing is activated, and control the indexing of messages on these components. Each parameter has a default setting, which you should only change if required; you can restore the default settings for parameters at any time. The following parameters are available:

• Maximum number of messages per package to be transferred to the TREX server
  When you activate indexing, an indexing service is scheduled, which uses a background job to periodically transfer any new or changed messages in packages to the TREX server for indexing.
• Maximum size in KB of message packages transferred to the TREX server
• Time interval in minutes for the periodic transfer of message packages to the TREX server for indexing
• Time interval in hours for the periodic reorganization of the index of a component on the TREX server
  A reorganization service is scheduled after the messages are transferred to the TREX server; this reorganization service deletes messages from the index after a specific, preconfigured retention period.
• Time period in days for the retention period of messages in the index
• Time interval in minutes for the periodic processing of the TREX queue
  When the TREX server receives the data, it stores it in a queue. A TREX queue is an index, which is periodically processed and which triggers the indexing of messages.
• Maximum number of entries for processing in the TREX queue

Selection Filters

You can create (and delete) filters to restrict the indexing of messages according to the specified selection criteria. If the filter is left empty, all messages on a component are indexed.

You can specify the following sender and receiver attributes as selection criteria:

• Party
• Component
• Interface name
• Interface namespace

All fields permit generic entries with an asterisk (*): Input help is available.

The values of the Interface Name and Interface Namespace attributes are combined with OR and applied to both interfaces (sender and receiver interfaces).

If you create multiple filters, these are combined with OR and identify the messages to be indexed.

When you save a filter, it is applied to all components on which message indexing is active.

Alert Configuration 

Purpose

You use the alert configuration to have the system inform you of errors during message processing. You can receive the alert by e-mail, fax, or SMS. In each case you will also find the alert in your alert inbox.

Prerequisites

You have fulfilled the prerequisites and performed the steps listed in Alert Notification Step-by-Step so that you can proceed with the alert configuration settings.

Process Flow

To configure your alerts, proceed as follows:

• Create the alert categories that you want to use in your alert rules.
• Create the alert rules in which you want to use your alert categories.

The following options are also available:

• Using various properties of the XPI Service: AF CORE, you can also control the connection of alerts from the Adapter Framework to the central monitoring server.
• Alerts from the Integration Engine are sent using the RFC destination CentralMonitoringServer-XIAlerts to the central monitoring server.This destination is created automatically as soon as the first alert is sent from the Integration Engine. The required technical settings and logon information are read from the exchange profile.

        NB : f you do not change the corresponding parameters in the exchange profile                         then the destination is not updated automatically. You can then either adapt                     or delete the destination manually. If you delete the destination then it is                         automatically recreated by the Integration Engine with the next alert. 

• You can configure a connection to CCMS and schedule the periodic transfer of alerts to CCMS.Once you have configured the connection to CCMS, choose Show CCMS Connection, select a period, and start the periodic transfer.A background job is scheduled that collects all unprocessed alerts and forwards the data to CCMS. You can also stop this job.
  The transferred data is displayed in a special CCMS Monitor.
• You can use the report SXMSALERT_LOGREADER to display log information for alerts that were reported by PI components. The report also shows whether an alert rule was found or not.

 Alert Inbox

Use

The alert inbox is user-specific and displays all the alerts for each alert server that have been generated based on the alert configuration.

An alert can be delivered to you by e-mail, fax, or SMS. In each case, you will also find the alert in your alert inbox, irrespective of the delivery method.

Integration

You can also call the alert inbox directly by calling transaction ALRTINBOX.

Prerequisites

• You have set up a central alert server.
• You have created alert rules.
• You have chosen Alert Inbox on the initial screen of the Runtime Workbench.

Activities

You can execute the following activities in your alert inbox:

• Confirm alerts and start a follow-up actionConfirmed alerts disappear from the inbox. You can also confirm alerts by e-mail, fax, or SMS. This also causes them to disappear from your alert inbox.
• Forward alerts to another user.
• Refresh the alert display.
• Subscribe or unsubscribe to the alert categories that you are permitted to use, in order to receive or not receive the corresponding alerts.
• Personalize alert delivery to meet your requirements.You can choose the type of delivery you want to use and a representative.

Cache Monitoring

Purpose

Cache monitoring displays objects that are currently in the runtime cache of either of the following receivers (cache instances) of cache data:

• Integration Server (ABAP Cache)
• Adapter Engine (Central and Local)
• Mapping Runtime Cache (Adapter Engines)
• Business Systems (with Web Service Communication)

Prerequisites

You have started the Runtime Workbench and have chosen Cache Monitoring on the initial screen.

Process Flow

In cache monitoring, different cache objects are monitored depending on the cache instance concerned. Selection criteria are available for each cache object; you can use these selection criteria to search for current objects in the runtime cache.

A table of hits is displayed. The content of this table varies depending on the cache object you have selected.

For most cache objects, you can display details for individual hits from the hit list. To do this, select the radio button in the first column of the relevant line.

Regardless of which cache object you select, you always have the option of calling a Notification Table that displays information about runtime cache updates and any problems that arose.

A Status Table lets you display the status of the last cache update for each cache instance.

How to connect SAP XI/PI/PO to Hana Cloud Integration(HCI/CPI)

In Eclipse Integration designer window,

• Go to Windows->Preferences

• From the Left hand side list, Select SAP Cloud Platform Integration->Repository Connection .
• In the new pop up window, provide the URL  and the credentials of your SAP PI.

NB : Provided your Eclipse should be in the network where PI is accessible.

After establishing the connection, we can import the PI structures to HCI.

• Go to File->Import , SAP Cloud Platform Integration->ES Repository content => Hit next.

• Here we get the list of things which can be imported.

• Select required fields and click Next and then Finish.

SAP XI/PI/PO tutorial for beginners

Introduction

SAP Net Weaver Process Integration (SAP PI) is SAP enterprise application integration (EAI) software, a component of the NetWeaver product group used to facilitate the exchange of information among a company's internal software and systems and those of external parties.

While implementing the SAP ERP in a large business establishment, it is found that not all sections can be brought under the SAP ERP. Many of the business sections may have their own proprietary tools, which are highly complex and may not be possible to replace. They run parallel to the SAP System. They are called the Legacy Systems. Then it becomes necessary to integrate between the SAP Systems and such pre-existing non-SAP System. This is where the SAP PI comes into play.

Why do we need SAP PI?

Apart from Legacy Systems, in a large business establishment, SAP ERP does not consist of a single system but several integrated systems i.e. CRM, SRM and FICO etc. To handle with such complexities SAP introduced Process Integration a platform to provide a single point of integration for all systems without touching existing complex network of legacy systems. This is a powerful middleware by SAP to provide seamless end-to-end integration between SAP and non-SAP applications inside and outside the corporate boundary. SAP PI supports B2B as well as A2A exchanges, supports synchronous and asynchronous message exchange and includes built in engine for designing and executing Integration Processes

Lifecycle of SAP PI

•       The first version of Exchange Infrastructure is XI 2.0 then XI 3.0

•       Exchange Infrastructure 2.0. Release Date : Dec 2003

•       Exchange Infrastructure 3.0. Release Date : Dec 2005

•       Process integration is from PI 7.0, PI 7.1, PI 7.11 & PI 7.30

•       Process Integration 7.0.   Release Date : June 2006

•       Process Integration 7.1.   Release Date : July 2008

•       Process Integration 7.11. Release Date : July 2009

•       Process Integration 7.30. Release Date : May 2011

•       Process Orchestration from PO 7.31, PO 7.4 & PO 7.5

•       Process Orchestration 7.31. Release Date : May 2012

•       Process Orchestration 7.4.   Release Date : May 2013

•       Process Orchestration 7.5.   Release Date : Oct  2015

•       Single stack ESB was introduced from SAP PI 7.30 released on May 2011.

Single stack and dual stack

When PI was first released, not all components were built on the same platform. Integration Engine and Business Process Engine was built in ABAP while Adapter Engine, Integration Builder, SL, CM and Mapping Runtime were built in Java. Therefore, PI needs both the Java and the ABAP environment to run and is known as the dual stack.

But in the later version all the components are built in Java. Some of the dual-stack components are either not used or modified to work on the Java stack. Therefore, PI needs only the Java environment to run and that is called single stack.

Architecture of SAP PI

We can divide the SAP PI into several areas

1. Integration Server
2. Integration Builder
3. System Landscape
4. Configuration and Monitoring

Integration Server can be termed as the Central Processing Engine of SAP PI. All the messages in PI gets processed here in this engine.

It consist of three different Engines. Those are

• Advanced Adapter Engine
• Integration Engine
• Business Process Engine

Advanced Adapter Engine

• Runs on Java stack.
• Converts native data to PI messages and vice versa.
• Forwards messages to Integration Engine for further processing.

Adapters in Advance Adapter Engine : FILE, JDBC, JMS, SOAP, RFC, WS-ADAPTER, REST SFTP, AS2, EDISEPARATOR, OFTP, X400, ODATA, SFSF, BC, CDIX, RNIF, RNIF11,

WS_AAE, HTTP_AAE, ICOD_AAE

Integration Engine

• Runs on ABAP stack.
• Processes the messages according to the configuration defined in the Integration Builder.
• Adapters in integration engine : IDOC and HTTP

Business Process Engine

• Uses SAP workflow Engine.
• Executes the Business Process Management (BPM) steps.

 Integration Builder is a client-server framework for accessing and editing integration objects and it consists of two related tools:

• Enterprise Service Repository – to design and develop objects to be used in scenarios
• Integration Directory – to configure the ESR objects to develop scenarios

Two together, we built integration processes which are commonly called scenarios.  

The System Landscape is a central repository of information about software and systems in data center and simplifies the administration of your system landscape.

In Configuration and Monitoring, we can monitor the messages and adapters.

A message in PI can be of two types:

Synchronous - has both the request-response part

Synchronous messages are flagged with Quality of Service (QoS) Best Effort. In this case,        

further processing in the sending application is blocked until a response is received.

Asynchronous - has either the request or the response part only

Asynchronous messages are processed with Quality of Service Exactly Once (equivalent to tRFC) or Exactly Once In Order (equivalent to qRFC).

In PI, message is represented by an interface.

Interface -> structure of the message in XML format + direction

Based on the above criteria, there are three types of interfaces

1.    Outbound interface         – connect to the sender system

2.    Inbound interface           – connect to the receiver system

3.    Abstract interface           – connect to the BPE

Architectural differences-AEX

 

SAP PI Homepage

The SAP PI tools Home screen looks like this

This home page can be accessed by using the tcode sxmb_ifr from your SAP GUI or using the URL: http://<host>:5<instance#>00/dir/start/index.jsp

The SAP PI home page consist of four main java links:

1.    Integration Builder : Enterprise Service Repository
2.    Integration Builder : Integration Directory
3.    System Landscape
4.    Integration Monitoring : Configuration and monitoring

Creating the products, software component and assigning Technical system and business system to the created products is done  in the System Landscape directory(SLD). Design these objects is done in the Enterprise Service Repository(ESR),configuration in the Integration Directory and monitoring in the Runtime Workbench.

Enterprise Service Repository
In SAP PI, Enterprise Service Repository is used to design and create objects to be used in the integration scenario. You can design Interface Objects, Mapping Objects and the different integration processes.

The following are the Interface Objects

·         Service Interface

·         Data type

·         Message type

Mapping of messages is done as per the sender and the receiver data structure

Integration process:

Operation Mapping is used for converting the source structure to target structure if data structure is different. Complex Operation Mapping can be simplified using Message Mapping.

Message Mapping can be implemented in the following ways −

• Graphical Mapping
• Java Mapping
• XSLT Mapping
• ABAP Mapping

Mapping is used for transformation of one structure (input) to another structure (output). And the transformation rules are defined by the mapping program. Mapping programs are developed at design time using Enterprise Services Repository or any other tool. These mapping programs are used at run time during the transformation of different structures using the configuration information provided using the Integration Directory.

Graphical Mapping

Can be designed by using graphical editor provided in the ESR.

XSLT and Java Mapping

• For these two, there is no tool support in PI. To make them available for the integration server, they have to be developed externally and imported into the ESR as JAR files.
• Can be designed externally and imported into ESR.
• Java mappings are implemented by using a specific class.
• XSLT mappings are designed by using various tools like Stylus studio, Altova XML Spy etc. as runtime supports XSLT processor.

ABAP Mapping

An ABAP functional module or program can be used for transforming messages.

Integration Directory

Here we make the pipe-line steps by configuring the ESR objects created earlier. These steps are executed by the integration engine during run-time.

Before we start the configuration we need to create/import the following objects in the DIR.

• ·      Service - Business System/ Business Service/ Integration Process
•      Communication Channel

Service allows you to address the sender or the receiver of messages. Depending on how you want to use the service, you can select from the following service types:

• Business System
• Business Service
• Integration Process Service

Communication channel determines the inbound and outbound processing of messages. The messages are converted from native format to soap-xml specific message format and vice-versa through the adapter.  Generally, there are two types of communication channel in a scenario: Sender Communication Channel and Receiver Communication Channel.

The pipe-line steps are created by creating the following 4 configuration in the DIR:

·         Sender Agreement − this determines how the message is transformed by Integration server.

·         Receiver Determination − this is used to determine information of receiver to whom message to be sent.

·         Interface Determination − this is used to determine the inbound interface to which the message is to be sent. This also determines the interface mapping for processing the message.

·         Receiver agreement − this defines how a message is to be transformed and processed by the receiver.

Aspects of an incoming message

Inbound Processing – Inbound processing defines how the incoming message has to be transformed technically to the XML message format that the integration broker can understand.

Routing - Defines to which receivers the incoming message is to be sent to. The configuration of routing may also include routing conditions.

Mapping - Defines how the business data of the message is to be transformed with regard to a particular receiver.

Outbound processing - Defines how the incoming message has to be transformed technically with respect to a specific receiver. Outbound processing again implies a technical transformation step: A transformation from the XML message format that the integration broker speaks to the protocol or standard that the receiver system can handle

Integrated Configuration

Integrated Configuration object allows configuring Local Processing in the Advanced Adapter Engine

New Directory object that includes multiple configuration objects into one and hence called “Integrated” configuration object.

Used for configuring local processing within advance adapter engine.

Integrated Configuration=Sender Agreement +Interface Determination + Receiver Determination+ Receiver Agreement.

The ICO is transferred as one single object to the AAE.

 

System Landscape

The System Landscape Directory contains the information about landscape and software component versions. A SAP system can be configured to register under this directory. System Landscape Directory (SLD) manages information about all installable and installed elements of your system landscape.

You can find the following links in a web page:

Landscape:

Under Landscape, you can find the following options −

• Technical Systems − You can view and define systems and servers.
• Landscapes − You can view and configure group of systems.
• Business Systems − You can view and configure business systems for use in Process Integration.

Software catalog

• Products − This is to view products in SAP software catalog.
• Software components − This is to view software components in SAP Software catalog.

Development

• Name Reservation − This is used for name reservation and also for NW development.

Products and components are the information about all available SAP products and components, including their versions. If there are any third-party products in the system landscape, they are also registered here.

Component Information are used in the ESR to define the Product and the SWCV.

Technical systems are application systems that are installed in your system landscape.

Business System are used in the Directory for defining the sender and receiver of messages.

Configuration and Monitoring

The Configuration and Monitoring option on SAP PI tools Home Page allows you to monitor the functions of the integration engine, CCMS integration and process monitoring infrastructure in SAP system.

It is the central entry point for monitoring purposes. This gives you the option of navigating to the monitoring functions of the Integration Engine, as well as integration with the Computing Center Management System (CCMS), and the Process Monitoring Infrastructure (PMI) of SAP.

• Component monitoring - monitoring the different SAP PI components (Java and ABAP parts).
• Message monitoring - tracking the message processing status within an SAP PI component and on error detection and analysis.
• End-to-end monitoring - monitoring of a message lifecycle from the SAP PI point of view.
• Performance monitoring - statistics about different performance aspects of SAP PI can be accessed through the RWB. Here, you can select and aggregate performance data, for example, by component, time range, or message attributes.
• Index administration - by administering and monitoring the indexing of messages per SAP PI component, you enable an index-based message search that you can use in message monitoring. This kind of message search offers you enhanced selection criteria including adapter-specific message attributes and terms or phrases from the message payload
• Alert configuration - by using the Alert Framework, central monitoring in PI can be provided with all errors reported during message processing in ABAP and Java. This enables an improved reaction to such errors in both the ABAP runtime and the Java-based Adapter Engine. For this purpose, the Alert Framework is provided with rules based on certain events and on information from the header of the PI message protocol. These rules determine whether alerts are send or not. If an alert is sent, it can be used for error analysis.
• Alert inbox - the alert inbox is user-specific and displays all the alerts for each alert server that has been generated based on the alert configuration.
• Cache monitoring - cache monitoring displays objects that are currently in the runtime cache. Different cache objects are monitored depending on the cache instance concerned.

      Adapters in SAP PI

   

1	RFC Adapter This is used to communicate with other SAP systems using RFC interface.
2	HTTP Adapter/HTTP AAE Adapter This allows the exchange of data using HTTP protocol. These adapters are available both in the Integration Engine and also in the Advanced Adapter Engine.
3	JDBC Adapter This allows access to databases.
4	File/FTP Adapter This is used to perform data exchange with external systems using a file interface or an FTP server.
5	Mail Adapter This allows you to connect e-mail servers to the Integration Engine.
6	IDoc Adapter This allows the exchange of IDocs. These adapters are available both in the Integration Engine and also in the Advanced Adapter Engine.
7	XI Adapter This adapter allows you to communicate using proxy. This adapter does not run in the Advanced Adapter Engine and runs in the Integration Engine. XI Adapter is used only for establishing the HTTP connection to the receiver.
8	JMS Adapter It enables communication with messaging systems using the JMS API.
9	WS Adapters This adapter is used to provide the connectivity with WS providers and WS consumers according to the standard Web Services Reliable Messaging (WS-RM) protocol. SAP has developed the WS-RM protocol with its own inbox, which is implemented in the ABAP stack on the Integration Engine.
10	SOAP Adapter It allows the integration of remote clients or Web service providers using SOAP.

   

   Transporting objects in SAP PI

In Order to know how the transport mechanism in PI works we will first look at the landscape that we are interested in.

We use this procedure to transport any PI object or integration flows with their referenced entities from a development to test environment or from a test to a production environment using the File or CTS+ transport type. The File transport type allows you to export the objects from a source system to a locally stored .tpz file and import the file into a target system. If you want to export objects from a source system and easily import to multiple target systems in a landscape, you can choose CTS+ transport type.

For SAP PI File to File Scenario, please go through the below link 
https://shijilkumar01sapxipipo.blogspot.com/2018/06/sap-pi-file-to-file-scenario.html