Tuesday, April 19, 2011

SAP PI Architectural Model, transports

The following table
defines the three high level architectural models in SAP PI deployment, followed by a real world
sample architectural progression. Advantages and disadvantages for each model will be discussed in
subsequent sections.

Central
A single integration server communicating with all business systems. Central
deployment of SAP PI is a favorable starting point for most organizations as it is
represents the smallest possible installation footprint and holds associated TCO
benefits. Deviation from this initial architecture requires careful justification due
to the increased complexity and associated impacts on business metrics such
as total cost of ownership.

Distributed

A single integration server with one or more de-central adapter engines
communicating with relevant business systems. It is often found in organizations
where performance or security reasons dictate a more complex solution
compared to centralization. This is a hybrid approach between central and
federated models giving the benefits around performance and security with the
benefits from centralized governance, maintenance and monitoring.

Federated
Two or more integration servers within a single landscape tier communicating
with relevant business systems. Use of additional de-central adapter engines
per integration server is also possible and adds a further level of complexity.
Due to the more complex architecture the federated model allows greater
flexibility however at the expense of a higher TCO. Such organizations are
usually larger in size and require a high degree of abstraction in their landscape.
Below are some customer driven reasons for federation:
  • Organization and divisional autonomy due to legal or operational reasons.
  • Separation of A2A and B2B integration scenarios for security reasons.
  • Separation by process types such as transactional versus master data.
  • Business continuity such as downtime minimization
  • Quality of Service obligations
  • Billing requirements based on volume
  • Security issues around personal data
  • Prioritization of messages
  • Geography
  • Technical Abstraction from upgrades & downtime
For More information click Here

SAP PI transports

SAP NetWeaver Process Integration 7.1 SP06 contains enhanced functionality that enables close
coupling between the PI development tools (Enterprise Service Repository and Integration Directory)
and CTS (Change and Transport System), and enhanced administration support during configuration
phase of TMS (Transport Management System) supporting the system maintenance of combined Java
and ABAP systems.
You would like to use this features in your SAP NetWeaver PI 7.1 SP06 systems.
Note
SAP NetWeaver PI 7.1 SP06 system is referred to as “PI system” in the remainder of this
document.
The following graphic describes the important CTS+ components and their distribution to the PI
systems for a typical three system landscape.


three system landscape consisting of DEV (PI Development System -PID), QAS (PI Quality Assurance
System -PIQ) and PRD (PI Production System - PIP).



for more informaiton Click Here

Monday, April 18, 2011

Selecting messages using the content of the message


The content based message search on the java engine was known in SAP PI 7.1 but as SAP decided to sunset /nwapi tool (which was not supported on production landscapes) there had to be an alternative for that. As of PI 7.3 we have a new way to configure and use content based message search on the java engine and this article will explain the steps involved.

In PI 7.3

PI/XI: Selecting messages using the content of the message in SAP PI 7.3 - tease <- click here

in PI 7.1

Payload Searching without TREX <- chick here

SOA Management->Monitoring->PI Message Monitoring
http://HOST:PORT/webdynpro/dispatcher/sap.com/tc~lm~itsam~ui~mainframe~wd/FloorPlanApp?applicationID=com.sap.itsam.mon.xi.msg.local&isLocal=true


NWAPI->Message Monitor
http://HOST:PORT/webdynpro/dispatcher/sap.com/tc~lm~itsam~ui~mainframe~wd/FloorPlanApp?applicationID=com.sap.itsam.mon.xi.msg



XML validation in SAP PI

PI 7.1: XML Validation in Integration Engine

In PI 7.1 validation functionality is available, so now with the help of PI 7.1 we can validate our incoming and outgoing messages in IE as well as in AAE corresponding to their structure i.e. XSD or DTD. This article describes XML Validation in the IE. In my next article, I will demonstrate how we can validate XML messages and message header in AAE.

There are couple of presentations on SDN, that’s tell about validation functionality in PI 7.1, but this article is posted in order to demonstrate the steps which are required to achieve it practically.

When we talk about XML validation in IE, then our incoming messages are validated corresponding to their schemas that are stored in File system. In PI 7.1 new Pipeline steps are introduced (“XML Validation Inbound Channel Request” and “XML Validation Outbound Channel Request”) to achieve validation.

If validation fails (Inbound side or Outbound side), then message processing will be stopped. Example, if we validate our incoming messages in IE and if invalid XML entered in IE then processing will fails in second step i.e XML Validation Inbound Channel Request”. In previous versions these messages fails in “Request Messaging Mapping” step.

So if validation fails in IE, Error description will be visible in MONI. It gives detailed error description and all structure errors information’s.

Important: If validation performed in IE, then sender will not get information about the failed structures. Administrator will look on these messages and can take further actions. In case of validation in AAE, adapter can send the error message to the sender.

“Fault Messages, Receipt Acknowledgement, Exceptions are not validated”.

Following steps demonstrate how we achieve the incoming XML validation in IE.

1. Design your objects in the ESR.

2. Configure your objects in the ID.

3. Required to validate incoming messages by IE, so check the option “Validation by Integration Engine” in Sender Agreement.

4. Create appropriate directory structure where we have to save our structure (xsd).

\usr\sap\\SYS\global\xi\runtime_server\\\\\\

A – validation
B – schema
C – GUID of the SWCV where service interface reside.
D – Repository Namespace where Service Interface is created.
E – Service Interface Name
F – Repository Namespace where Message Type or External Definition is assigned.

Note: if your ESR namespace contains special character then do replace it with “~” in folder name.

If namespace is http://farooq.com/XI/FileToFile then folder name should be
http~farooq.com~XI~FileToFile

Export schema from the ESR and save it in folder “F” with name<>.xsd. So in this case it is MT_File_Sender.xsd

5. Testing of the Scenario.

In this example, all designed values for source MT are mandatory. What happen if ZIP tag is missing in sender message or payload.

In XML document ZIP is missing

Message fail in IE and message processing stopped. The Error description is appropriate for the administrators.

Similarly we can validate outgoing messages in IE by selecting an option “Validation by Integration Engine” in Receiver Agreement

for More info: http://www.riyaz.net/blog/pi-71-xml-validation-in-integration-engine/technology/sap/525/