Interfacing production and maintenance data from the PI Sytem to SAP

Today in a company, there exist pools of legacy systems processing data and having dependency on each other. Hence, it is almost impractical to even think of removing those systems. Large amount of crucial data is processed by these systems in traditional ways.

In SAP systems, the Intermediate Documents (IDOCs), Business API’s (BAPI) are standard mode of data exchange. Non-SAP systems also use numerous proprietary approaches to share information. Altering with these complex systems means putting your head in crocodile jaws.

To handle with such complexities SAP introduced Process Integration (PI) a platform to provide a single point of integration for all systems without touching existing complex network of legacy systems.

SAP Process Integration (SAP PI) formerly called SAP Exchange Infrastructure (SAP XI) is an integration platform to provide a single point of integration or all 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 (Business to Business) as well as A2A (Application to Application) exchanges, supports Synchronous and Asynchronous message exchange and includes a built in engine for designing and executing Integration Processes.

You will have a glance at SAP PI integration perspective for various types of integrations but before that I would like to give you a high level architectural overview of SAP PI.

Effective B2B and SAP Integration

There are a number of factors that should be taken into consideration when integrating B2B and SAP systems. A service provider solution, such as GXS Managed Services, greatly simplifies this integration with your trading partner community as you only need to be concerned with the integration between your SAP system and the service provider. However, there are still a number of integration options that need to be considered:-

 

SAP process integration

Advantages of service-oriented architecture

  • SAP process integration is an EAI platform (middleware) that offers you the traditional advantages of integrating your business processes into service-oriented architecture.
  • We identify solutions and concepts to help you achieve reliable and effective process integration of your business process on the basis of a modern, service-oriented corporate architecture.
  • Enterprise services and services will lower your integration costs and significantly improve your communication with your business partners. (B2B and B2C processes)
  • Business processes are monitored end-to-end: Starting with analysis through to design and development, implementation all the way to operation and modification – the entire life cycle of a service is mapped.
  • For business-critical processes, performance and stability are guaranteed by the scalability and message throughput in highly available IT system environments.

 

Interface and PI migration/update

Predictable operating costs with the greatest possible functional scope

  • New software releases contain greater functionality. The improved technology standards help you adapt your business processes to changes over time.
  • The operating and maintenance costs can be calculated and are not a continuously growing cost factor as a result of older release versions.
  • Harmonising data flows as well as changing business requirements can be synchronised with the upcoming projects in a roadmap through extensive update planning and/or migration plans.
  • Consistency between high-performance hardware and software updates in life cycle planning allow for effective and time-saving IT management with simultaneous risk optimisation.
  • Small to large system environments makes it possible to competently implement various interface technologies

 

Managing Business System Details

Use

After you create a business system, you can change the following details about the business system:

  • Business system role
  • Related integration server
  • Integration server pipeline URL
  • Group
  • Associated technical system
  • Logical system name
  • Installed products.

In addition, you can define a transport target for a business system. A transport target is a business system to which the source business system transports content. By means of transport targets, PI content is transported between different groups of business systems.

Process Integration (PI)

Purpose

With the usage type PI, you can integrate applications from one or multiple systems. SAP differentiates between the following areas:

●     Cross-system application integration, which does not focus on individual end-user actions. Applications can be company-internal, cross-company, SAP or non-SAP applications. The SAP usage type PI incorporates all functions that were previously a part of SAP Exchange Infrastructure (SAP XI).

●     The modeling, administration, and automation of user-driven processes within SAP systems. From a technical viewpoint, a core function of the run-time is that you can save the state of a previously-modeled process and call it up at a later stage, if the process is to be continued as a result of a particular action or event. Since the execution of processes can be useful when integrating applications across system boundaries (without user actions), relevant functions within SAP are reused for this purpose. Together, the functions referred to here are known as Business Process Management.

 

Design

Internal Company and Cross-Company Application Integration

Applications in a heterogeneous system landscape run on a variety of different systems and platforms.In the long run, it is not cost-effective to integrate all these systems by using point-to-point connections because developers and consultants would need to analyze the implementation in each individual system to get a clear overview of the entire process. As a result, the architecture for application integration in SAP focuses on storing the relevant application integration information centrally. The following figure provides an overview of how to integrate applications with SAP.

PI

 

The knowledge required to integrate applications is known as collaboration knowledge. To develop and configure this knowledge centrally, developers and consultants work with the Integration Builder. Developers use this tool to define the design of cross-system applications in the Integration Repository. At a later stage, consultants configure this content in the Integration Directory, tailoring it to the particular system landscape of the customer. The System Landscape Directory acts as a central information database, from which the relevant products and systems of the system landscape can be queried for development and configuration purposes, and at runtime.

At runtime, the Integration Server analyzes the data from the Integration Directory and the System Landscape Directory to process and forward messages from senders. In this way, you can develop applications that integrate SAP applications, external applications, marketplace applications, and middleware components from third-party suppliers. The architecture supports the integration of both internal company and cross-company applications.

 

Business Process Management

Along with functions from other usage types, Business Process Management covers the modeling, administration, and automation of both more complex cross-system (unbounded) processes and processes embedded in an SAP application within a system. SAP uses the same BPM runtime to execute both unbounded and embedded processes: In the context of unbounded processes, it is known as the Business Process Engine, in the context of embedded processes, it is known as the Workflow Engine.

Unbounded Processes

In the case of complex cross-system processes, stateless processing of messages with the Integration Server is sometimes not sufficient. Developers create integration processes in the Integration Repository to be able to correlate messages and execute more complex processes by means of loops. At runtime, the Integration Server executes these processes on the Business Process Engine and stores information about processes that have already been started and those that are not yet complete.

1

To send messages from an integration process, the Business Process Engine works closely with the Integration Engine of the Integration Server. When the Integration Server sends messages using an adapter, the Integration Engine works closely with the Adapter Engine.

 

Embedded Processes

Using workflows in SAP, you can define user-driven processes and connect existing SAP applications to each other. A simple example of a workflow is the automated processing of a leave request: An employee creates a leave request which is then sent to the relevant manager. If the manager approves the request, the employee receives a corresponding notification and the leave is recorded in the system. The manager can also reject the leave request. You model the process flow and subsequent steps of user actions by using a model, which the Workflow Engine processes at runtime. Unlike unbounded processes, processes defined by using workflows are embedded in an SAP system.

2

 

 

Post a comment