Hidden Parameters in ESR & ID

DATA TYPE:

We find the below options in Data Type Editor:

 Classification
 Qualify schema
 Occurrence

Use:

Data type is an interface object that defines the structure of data in message types in the ES
Repository. They contain elements and properties for the type definition. Data types are
defined using XML Schema Definition Language (XSDL).

Classification:

There are different classifications of data types in the ES Repository:

 Core Data Types and Aggregated Data Types:

The specification XML Naming and Design Rules by the United Nations for Trade
Facilitation and Electronic Business (UN/CEFACT XML NDR) describes how
syntax-free components, which have been developed according to ISO 15000-5 Core
Components Technical Specification (CCTS), are represented systematically in XML
schema and XML instances. Core data types and aggregated data types are defined
according to these standards. In addition to the language elements of XML schema,
the data type editor also has attributes for the definition of the data types that comply
with CCTS. These can be evaluated when the data type is used elsewhere. This,
together with the governance process for data types simplifies the development of
cross-company processes and the development of user interfaces.

 Freely-Modeled Data Type:

Freestyle data types support XML schema only.

Message types in the ES Repository can reference freestyle data types, core data types, and
aggregated data types.

XML schema is the basis for the description of data types, regardless of the selected
classification. The following sections describe some of the basic concepts.

XML schema has the following data type categories:

Category Meaning Examples
Built-In Built-in data types xsd:string
Type are part of the XML
schema language xsd:decimal
and have the prefix
xsd. (They can xsd:integer
also be subdivided
into primitive and
derived data types,
but this is not
important in the
definition of data
types). XML
schema defines a
value range for
each built-in data
type.
Simple Simple data types <simple
Type refine built-in data Type name=germanPhoneNumber base=string> <pattern
types, for example, value=?\d{4}?/?\d{6} /> </simpleType>
by limiting the
length of a string or
by specifying a
specific value
range. Like built-in
data types, they do
not contain any
further elements.
Complex Data types that can <complexType name=person> <element name=firstname
Type contain further type=string /> <element name=lastname type=string />
elements and </complexType>
attributes. Elements
and attributes can in
turn reference built-
in, simple,
complex, or global
data types. This
enables large
complex data types
to be structured
using smaller
complex data types.
Complex Complex types with
Type simple Content are
with data types with a
Simple root element that
Content has a textual XSD
type (for example,
xsd:string), but that
otherwise only have
attributes and sub
elements.

Qualify Schema:

Elements and Attributes:

To describe complex data types in XML schema, use elements and attributes:

Node Use Example Instance

Type
Element Create structured data types. Elements <myElem> <f1> Value of f1
that have a type cannot contain sub </f1> <f2> Value of f2 </f2>
elements. </myElem>
Attribute Add attributes to elements. Attributes <myElem myAttr =" AttributeValue
cannot usually have sub nodes. "># Element Value #</myElem>

The difference between elements and attributes is that attributes cannot have any sub nodes,
and that the same attribute cannot be used more than once in an element.

XML schema does not recognize tables but permits instead the definition of elements that
can occur frequently in a schema (max Occurs=unbounded). Depending on the target
language, proxy generation generates either a table type with a structure for the line type
(ABAP), or class for accessing using a list (Java).

Occurrence:

Occurrence is nothing but the number of times a given XML tag appears in the XML
document. Occurrences are defined in the data type editor and a minimum and maximum
occurrence is specified for each field.

For example, the Occurrence of the source field is 1:1. Occurrence 1:1 indicates a minimum
and maximum occurrence of 1 i.e. it should be present once.

If the occurrence is 1: outbound means minimum occurrence should be once but maximum
can be ‘n’ number of times.

Service Interface:

We can find below options under service interface in ESR:

 Category
 Interface pattern
  Security profile
 Event interface
 Sensitive data
 Attributes
 WSDL

Use:
A service interface enables you to describe - independently of a platform or programming
language - operations that you require later for an implementation in the application system
at a later stage. Depending on the category of a service interface, the following use cases are
possible:
Category:

 Inbound (Provider Role): You want to implement a service in an application system,

which can be called by a user. It means if we want to send data from source to XI, we
go for Inbound (Sender).
 Outbound (Consumer Role) you want to call a service of a provider. To do so, you
require the outbound service interface that matches your inbound service interface. It
means, if we want to send data from XI to Target (Receiver).
 Abstract In enhanced communication using the Integration Server; you want to
exchange messages with a buffered integration process or BPM scenarios. It acts as
both inbound and outbound.

Interface Pattern:

You assign each service interface an interface pattern, which describes the type of the
communication to be executed. Before we describe the interface patterns Stateless (XI 3.0-
Compatible), Stateless, Stateful, and TU&C/C, it is necessary to clarify the terms stateless
and Stateful:

 Stateless communication means that the messaging runtime does not support the
saving of a status at the provider once the messaging runtime has completed the
message exchange successfully.
 Stateful communication means that the messaging runtime supports the saving of a
status at the provider once the messaging runtime has completed the message
exchange successfully.

 Stateless

For this interface pattern, the Web service runtime supports point-to-point
communication using Web services as well as communication using the Integration
Server with the help of the Web service adapter.

 Stateful

Successive calls use a state at the provider. This interface pattern is only needed for a
few special technical scenarios. It does not guarantee a common update of data at the
receiver.
 You cannot use this interface pattern for enhanced communication using the
Integration Server. Only synchronous stateful communication is supported.

 TU&C/C

An interface pattern that is based on the existing protocols for synchronous and
asynchronous communication and enables cross-system ROLLBACKs (see below).
This interface pattern supports both point-to-point communication using Web services
and communication using the Integration Server with the help of the Web service
adapter.

The selected interface pattern determines how an application developer programs

communication in the back end. If you change the interface pattern, the application program
in the back end must also be changed. This applies if the interface pattern is changed from
Stateless (XI 3.0-Compatible) to Stateless, and for any other changes.

Tentative Update & Confirm/Compensate (TU&C/C):

For cross-system updates, it is better to work with asynchronous communication, because the
quality of service Exactly Once (In Order) (EOIO) guarantees that a message is delivered
once (in the case of EOIO in the correct order), even after a system crash.

However, if the continuance of a transaction depends on the results of a service call, you can
work with a synchronous call. In this case, calls within a component are unproblematic:
When the called service updates changes in the system, these updates are part of the calling
transaction. The caller determines for the whole transaction whether the system writes the
changes to the database (COMMIT) or not (ROLLBACK). There is no such automatism for
cross-system service calls. Instead, you can ensure the consistency of the data by using the
TU&C/C protocol.

Stateless Communication (XI 3.0-Compatible):

This interface pattern is relevant only if you have SAP NetWeaver Process Integration
installed in your landscape.

With this interface pattern, you can continue to use all existing protocols (up to SAP
NetWeaver 2004s) in the back end that were developed on the basis of message interfaces.
Message interfaces from the Integration Repository of SAP NetWeaver 2004s are migrated
to service interfaces in the Enterprise Services Repository and are assigned this interface
pattern. The interface pattern only allows one operation.

Security Profile:

You can assign security levels to the service interfaces in the ES Repository. These values
form the metadata descriptions which influence the behavior during implementation of this
service definition. This feature is applicable only for point to point communication. You can
assign different set of values to security profiles. Depending on the type of interface pattern
selected, you can choose from different set of values for the security profile.
  If you select the interface pattern as Stateless (XI30-compatible) , you can
choose from the following values:
o Basic - Basic Authentication using user ID and password and no transport
security.
o Strong - Strong Authentication (SSL or SSO) and transport security.

Note

The Security Profile field is available only if you select the Point- to-Point enabled
checkbox.

 If you select the interface pattern as Stateful , Stateless , or TU&C/C , you can
choose from the following values:
o No - No Authentication and no transport security.
o Low - Basic Authentication using user ID and password and no transport
security.
o Medium - Basic Authentication using user ID and password and transport
security.
o High - Strong Authentication (SSL or SSO) and transport security.

Event Interface:

To define a business event that can be consumed by other applications as Web

services, select the Event Interface check box.

Note: An event is an outbound service interface with multiple asynchronous

operations. When you mark a service interface as event, the event classification is
assigned to it.

Sensitive Data:

If you want to enable the encryption at run time for a service interface, then
select the check box for sensitive data.

Note: You can use this feature if you run scenarios that involve the exchange of
sensitive data and you want to prevent malicious users from accessing this data.

Attributes:

Mode and Messages:

Mode Messages
Asynchronous Request , fault (optional and only for inbound service interfaces)
Synchronous Request , Response , Fault (optional)
If you want to handle application-specific errors or persist them in monitoring, assign
corresponding fault message types to the operation. Fault messages transfer errors on the
receiver side to the sender or to monitoring. For this reason, it is not possible to define fault
messages for asynchronous operations of abstract service interfaces or for asynchronous
operations of outbound service interfaces.

A process can be defined as either synchronous or asynchronous.

A synchronous process is invoked by a request/response operation, and the result of the

process is returned to the caller immediately via this operation.

An asynchronous process is invoked by a one-way operation and the result and any faults
are returned by invoking other one-way operations. The result is returned to the caller via a
callback operation.

WSDL:

The Web Services Description Language (WSDL) is an XML-based interface definition

language that is used for describing the functionality offered by a web service. The acronym
is also used for any specific WSDL description of a web service (also referred to as a WSDL
file), which provides a machine-readable description of how the service can be called, what
parameters it expects, and what data structures it returns. It thus serves a purpose that
corresponds roughly to that of a method signature in a programming language.

The current version of WSDL is WSDL 2.0. The meaning of the acronym has changed from
version 1.1 where the D stood for Definition.

Receiver Determination:

Under Receiver determination, we find the following content:

 Type of receiver Determination

 Operation specific or not specific
 If no receiver found, proceed as follows

Types of Receiver Determination:

There are two options for determining how receivers are determined:

 Standard

If you want to specify the receivers of the message (and optionally routing conditions)
manually, select this receiver determination type. You can also specify conditions that
refer to the content of the message.

For a standard receiver determination you can also specify whether the configuration
settings are valid for all operations of the outbound interface or whether they are to be
defined separately for each operation.
  Extended

If you want to determine the receiver of the message dynamically at runtime by means
of a mapping, select this receiver determination type.

Defining Standard Receiver Determinations:

If you select this option, you can specify the receivers of the message (and optionally routing
conditions) manually in a receiver determination.

The combination of one or more receivers with a condition is referred to in the following as a
rule. You have the following options for specifying rules:

 Specify local rules

You define a local rule for one receiver determination and this applies only to
messages whose address fields in the header match the key of the receiver
determination.

 Insert (reusable) receiver rules

A receiver rule is a reusable rule that is defined as a separate object in the Integration
Directory. It contains receiver and routing conditions and can be used by multiple
receiver determinations.

Caution:

Note that you cannot specify expressions using XPath when you define conditions in
receiver rules.

Prerequisites:

You have created a receiver determination and selected the type Standard.

Procedure:

1. First specify whether you want to define the receiver determination operation-
specifically or for all operations of the outbound interface (radio button).

If you want to define the receiver determinations operation-dependently, all operations

are displayed that were defined for the outbound interface in the key of the receiver
determination.

In this case, first select the operation for which you want to define the receiver
determinations and then proceed with the next steps.

2. You have the following options for specifying receiver and routing conditions:
 o Specify Local Rule

Add a local rule for receiver determination and enter a combination of receivers
and conditions.

o Insert Receiver Rule

If a specific receiver rule exists for the configuration you want, you can use this
and add it to the receiver determination.

To do this within the Configured Receivers frame, choose the arrow beside the
Insert Line below Selection ([PICT]) icon and choose Insert Receiver Rule. Call
input help for the Rule column and select the receiver rule.

Defining Extended Receiver Determination:

Use:

When using routing conditions, the receivers of a message are determined at runtime by
evaluating the condition (which depends on the content of the message). However, the names
of the receivers have already been defined at configuration time in the Integration Directory
(integrated configuration, Receiver tab).

When you configure routing that way (referred to as standard receiver determination ), you
have to specify the receiver names as part of the configuration procedure in Integration
Directory.

A more flexible way to configure routing is offered by the extended receiver determination .

In an extended receiver determination, you can specify a mapping program that takes over
the task of finding out the actual receivers at runtime. You can design the mapping program
that way that the receivers of the message are read from a list that might be part of an
external data source (mapping look-up approach).

This approach has the following advantages:

 Storing receiver names in an external data source allows to update of the receiver list
without the need of a cache refresh.
 Storing receiver names outside the Integration Directory allows non-integration
experts to maintain receivers.

Note:

This section applies to the use case when configuring message processing using the
Advanced Adapter Engine only.

Procedure:

1. Define a suitable mapping in the ES Repository.

 In particular, do the following:

o Define an operation mapping and assign the abstract service interface

ReceiverDetermination as the target interface. The service interface
ReceiverDetermination is in the Enterprise Services Repository in the software
component SAP BASIS (namespace http://sap.com/xi/XI/System).

Define the message mapping or mapping program that is to determine the

receivers at runtime. Assign this message mapping or mapping program to the
operation mapping specified before.

2. Define an integrated configuration in the Integration Directory

Enter the outbound interface of the operation mapping from above in the key of the
receiver determination as the outbound interface. Assign this operation mapping to the
receiver determination. Furthermore, define outbound processing (sender adapters) for
all configured possible receivers.

Note:

As for AEX no wildcards (*) can be used to mask the key of configuration objects,
you need to specify the name of the potential receivers when defining the integrated
configuration.

Note :

If the mapping program returns an XML file with empty or missing <Service></Service>
tag, the message is routed to the default receiver (that is configured in the integrated
configuration, Receiver tab, under If No Receiver Is Found, Proceed as Follows , option
Select the Following Receiver:

Operation specific or not specific:

If you define the receiver determinations as operation-specific, all operations are displayed
that were defined for the outbound interface in the key of the receiver determination, and
you can assign the receiver based on the operations, in other words-- different operation
may have different receiver.

If no receiver found, proceed as follows:

Procedure if No Receiver Found at Runtime:

Even if you have defined the routing correctly in the integrated configuration, it is possible
that the receiver of a message cannot be determined at runtime.
Example:

If you define a condition depending on the contents of a message, it can happen that the
current inbound message does not contain the application data required to fulfill the
condition.

You can specify what is to happen at runtime if this occurs. You have multiple options. In
the Configured Receiver frame, select the relevant radio button under If No Receiver Is
Found, Proceed as Follows.

Setting Behavior at Runtime

Error message Message processing is terminated with an error.

You can correct the configuration and restart the message processing.

Recommendation

Select this setting when the underlying scenario is modeled in such a

way that a receiver must always be found at runtime. If a receiver is not
found at runtime, it is the result of a possible configuration error.
Ignore Message processing is ended as defined by your configuration settings.
Since no receiver is determined, the subsequent pipeline steps
(determining the inbound interface, mapping, outbound processing) are
not processed. An error message is not sent to the sender. When you
select this setting, you cannot execute the message again.

Recommendation

Select this setting when messages for which no receiver can be found
can typically occur in the underlying scenario.
Continue Message The message is sent to a fixed predefined receiver. You can specify the
Processing with the receiver in the Party and Communication Component fields (using
Following Receiver: input help).

Note:

These settings apply to asynchronous messages only. If a receiver cannot be found in

synchronous communication, an error always occurs.

Sender Agreement:

Under sender agreement tab, you can find below options:

 Schema validation

Schema Validation:
You can specify whether you want the structure of the payload of the inbound message to
be checked.

If you want to have the message validated, you have the following options:

● Validation by the sender adapter

● Validation by the Integration Engine

1. For XML validation to be executed correctly, you must specify the software component
version of the interface that is entered in the key for the sender agreement. Only then is it
possible to define the message structure uniquely. Use the input help for the Software
Component Version field.

2. If you want the message to be validated, select Validation by Adapter or Validation by

Integration Engine.

XML Validation:

XML validation allows you to check the structure of a PI message payload. The structure
check is performed using saved data types. You activate the validation in the collaboration
agreement. Monitoring and administration takes place in message monitoring of the
Runtime Workbench and in the Integration Engine.

There is no semantic check of the message payload. Fault messages, receipt

acknowledgments, and exceptions are not validated.

You can perform the structure check at the following points in PI message processing:
 ● Validation in the sender adapter

If the sender adapter has created the PI message, you can then perform the validation of
the PI payload. If the structure of the payload differs from the definition of the data type
provided for comparison, message processing is stopped. The adapter sends a
synchronous response to the sender of the message, informing it about the structure
error. The industry-specific adapters inform the sender asynchronously, as required by
the RNIF protocol and the CIDX protocol.
All sender adapters (including non-SAP adapters) can perform this validation.
● Validation in the Integration Engine

In inbound and outbound processing, validation of the PI message payload takes place
as a pipeline step of the Integration Engine. If the structure of the message payload does
not match the saved definition of the data type, an error description is generated. The
error description contains status information and a list of all structure errors. Message
processing is stopped. The message is set to error status and an error report is saved.

If validation takes place in the Integration Engine, the sender of the message is not
automatically informed of the structure error. The message is set to error status and an
administrator can process the message further using the Runtime Workbench.

Handling Synchronous Messages:

Synchronous messages consist of a request and a response payload, which are processed in
a synchronous call. Both payloads can only be validated together. You configure the
validation for inbound requests and outbound responses in the sender agreement. You
configure the validation for outbound requests and inbound responses in the receiver
agreement.

Configuration:

You define whether and where the validation of the PI message payload takes place in the
respective collaboration agreement. In a sender agreement, you can choose between
validation in the sender adapter or validation in the Integration Engine. If validation takes
place in the adapter, a synchronous response is sent to the sender when an error occurs.

In the receiver agreement, you can configure the validation in the Integration Engine. If
validation takes place in the Integration Server, the message is set to error status and can
be processed by the administrator in the Runtime Workbench in the case of an error.
Administration in the Runtime Workbench and in the Integration Engine:

Messages that have error status following validation can be processed further by an
administrator in the Runtime Workbench. The administrator can resend messages and skip
the validation step.

Receiver Agreement:

Under receiver agreement, we can see the following parameters:

o Schema Validation
o Header Mapping

Schema Validation:

You can specify whether you want the structure of the payload of the outbound message to
be checked.

1. For XML validation to be executed correctly, you must specify the software
component version of the interface that is entered in the key for the receiver
agreement. Only then is it possible to define the message structure uniquely. Use
the input help for the software component version field.
2. If you want the messages to be validated, select Validation By Integration Engine.

Header Mapping:

Use:

You use Header Mapping to map the values of the following key fields in the receiver
agreement to other values.

 Sender Party
 Sender Communication Component
 Receiver Party
 Receiver Communication Component

The Header Mapping is particularly important when configuring Business-to-Business

processes in which the business partners want to replace the names of their internal business
systems with neutral representatives (party, business component)

Prerequisite:

 You have created an integration flow in your Integration Directory and configured the
systems, interfaces and channels.
 You have assigned an adapter to the receiver channel that supports header mapping.

Note: The following receiver adapters support header mapping:

 o CIDX Adapter
o RNIF Adapter 1.1
o RNIF Adapter 2.0
o Plain HTTP Adapter
o IDoc Adapter

Context:

You use this procedure to mask the names of systems within your landscape while
communicating with an external business partner in a B2B scenario. Since you cannot show
the names of internal systems to the external partner, you allow the partner to see only the
names of the exposed communication components in the received messages. Using header
mapping, you can mask the system details in the message header with parameters such as
Sender Party, Sender Communication Component, Receiver Party, and Receiver
Communication Component, which an outgoing message carries in its header. You can either
select a specific system and party name or allow dynamic determination of values for the
header mapping parameters by using Xpaths or Context objects.

The figure below shows how the header mapping is used in a B2B communication and is
followed by an explanation:

In the figure above, two integration flows are configured, one with the landscape details of
Business Partner 1 and the other with landscape details of Business Partner 2, to enable B2B
communication. When Business Partner 1 sends messages to Business Partner 2, the
BusinessPartner1_Receiver system forwards the message to BusinessPartner2_Sender
system. When the message is sent across the landscape, the header Mapping feature at the
BusinessPartner1_Receiver system masks the internal system details in the message header
of the outgoing message. So, the message received by Business Partner 2 sees only the
masked names for the system details of Business Partner 1.

Procedure:

1. In the Model Configurator editor, select the receiver channel.

2. In the Properties view, choose the Header Mapping tab.
3. Choose the Sender Communication Component field and select the type of value, an
Xpath, Context Object or Service.
4. Choose Browse... and select a corresponding value.

Note:

If you have chosen Service and the selected sender communication component
belongs to a party, the Sender Communication Party is auto-filled.

5. Perform steps 3 and 4 for Receiver Communication Component and Receiver

Communication Party.
6. Save the changes.

If we want to replace the internal name of a sender business system in the outbound
message with a neutral name of a party and communication component, specify the fields
for sender party and sender communication component in the Header Mapping.

Integrated Configuration:

Under ICOs Tab we can see below options:

 Staging
 Logging

Staging:

Saving Message Versions in the AAE (Local Message Processing):

Use:

You can save asynchronous messages that are processed in the Advanced Adapter Engine
(AAE) either before or after processing steps.

You can then edit the message and, in special cases, restart processing of the changed
message.

Note:

This kind of saving message versions is also called staging (in contrast to message logging
where synchronous messages are saved and only can displayed).
When you have configured local message processing using the AAE (using integrated
configuration), you can store message versions after the following processing steps within
the pipeline:

Processing Step Description

Message preparation After sender adapter processing, the message is handed over to
(parameter BI) the messaging system and prepared for further processing.
Inbound XML validation The inbound message is validated against a schema.
(parameter VI)
Receiver and interface The receivers of the messages and the inbound interfaces are
determination (parameter evaluated based on the configuration settings in the
MS) corresponding integrated configuration in Integration Directory.
Mapping (parameter AM) The mapping is performed based on the configuration settings in
the corresponding integrated configuration in Integration
Directory.
Outbound XML The outbound message is validated against a schema.
validation (parameter
VO)

The following figure shows the sequence of processing steps for local message processing in
the Advanced Adapter Engine and also indicates where message versions can be stored:
Figure 1: Processing Steps within the AAE

You can use parameters BI, VI, MS, AM, and VO to define whether a message version is to
be saved and how further processing is to proceed. You have the following options to define
the mode of further processing for each step:

 0 (MODE_NO_STORE)

The processor does not save message versions; it continues with the next processing
step.

 1 (MODE_STORE_ON_ERROR)

The processor only saves a message version if an error occurs in the next processing
step.

 3 (MODE_STORE_AND_RETURN)

The processor saves the message and continues with the next processing step.

Note:

At least one of the steps must be configured with value 3.

To configure the saving of message versions, use parameter xiadapter.stage.conf,
which belongs to the service XPI Adapter: XI.

Procedure:

Global Configuration of Staging:

1. Call SAP Net Weaver Administrator.

You can use the following address: http://<host>:<port>/nwa

2. Choose Configuration Management Infrastructure Java System Properties .

3. On the Services tab, select XPI Adapter: XI .
4. Enter values for the xiadapter.stage.conf property.
o You can enter 0, 1, or 3 for each processing step ( BI, MS, and so on).
o Enter the values in the following format: BI=1, MS=3, ...
o You can make additional entries for dual-stack scenarios where also the
Integration Engine is involved in message processing by putting the variable set
in parentheses and add a second variable set, also in parentheses. The first
variable set applies to local message processing in the Advanced Adapter
Engine; the second variable set applies only to those scenarios that include also
message processing on the Integration Engine.

Example:

(BI=1, MS=3) (MS=3)

o The parameters AM and VO cannot be used for dual-stack scenarios (second

variable set). These parameters only apply to local message processing using the
AAE.
o If you do not make any entries, the message is saved in the Advanced Adapter
Engine after receiver determination.

This corresponds to the entry MS=3.

Scenario-Specific Configuration of Staging:

You can also configure staging for specific scenarios that are covered by the integrated
configuration.

For more information, see the documentation of the Integration Directory in SAP Net
Weaver Library under SAP Net Weaver Library: Function-Oriented View Process
Integration Integration Directory Defining the Integrated Configuration .

Result:

If a message is not delivered, the last saved message version is used for an automatic restart.
If the time limit for an automatic restart has been exceeded and the message has the status
Not Delivered, you can use each saved message version for a manual restart.
If you use a message version for the manual restart and later message versions exist, the
message version number is increased to distinguish it from the other message versions.

Note:

Note that when a message is restarted, it will be scheduled in a queue again. As a result of
this, the processing time of a message might be extended when staging is applied. The
message is rescheduled within the pool of messages already available in a queue.

Logging:

Configuring Message Logging (Within AAE Pipeline):

Procedure:

Configuring Message Logging at Specific Processing Steps:

You configure this kind of message logging in SAP NetWeaver Administrator.

1. Start SAP Net Weaver Administrator from the following page: http ://< host>:<port>.
2. Choose SAP Net Weaver Administrator.
3. Choose (tab) Configuration Infrastructure Java System Properties .
4. To specify message logging, in tab Services search for XPI Adapter: XI.

This is the service for pipeline processing of the XI message protocol.

5. On the Properties tab (under Extended Details) search for xiadapter.logger.conf.

6. To specify message logging behavior, choose Modify , and in field Enter Custom
Values enter the corresponding value according to the following syntax:

<Processing step> = <condition>

You can separate multiple expressions like that by commas.

As processing step, you can specify one of the following steps within the pipeline processing
(indicated by a two character string as shown in the table):

Processing Step Description

Message After sender adapter processing, the message is handed over to the
preparation messaging system and prepared for further processing.

(parameter BI)
Receiver The receivers of the messages are evaluated based on the configuration
determination settings in the corresponding integrated configuration in Integration
Directory.
(parameter MS)
Mapping The mapping is performed based on the configuration settings in the
corresponding integrated configuration in Integration Directory.
(parameter AM)

The message is logged after the specified step.

To specify the logging condition, you use integer values. The following table lists the
possible digits:

Digit Condition
1 Asynchronous messages are logged.
2 Synchronous messages are logged.
3 Synchronous and asynchronous messages are logged.
5 Only asynchronous error messages are logged.
6 Only synchronous error messages are logged.
7 Synchronous and asynchronous error messages are logged.
9 As setting 1, with the business content (payload) hidden.
10 As setting 2, with the business content (payload) hidden.
11 As setting 3, with the business content (payload) hidden.
13 As setting 5, with the business content (payload) hidden.
14 As setting 6, with the business content (payload) hidden.
15 As setting 7, with the business content (payload) hidden.

As default, no value is assigned, which means that messages are not logged.

Note:

The conditions are derived by summing up the “basic” values 2, 4, and 8.

Example:

The complete expression: AM=14 means: synchronous error messages are logged between
mapping and schema validation, and the business content is hidden.

Note:

Logging configuration for AAE pipeline is automatically propagated.

That means, for example: if a log version was stored during pipeline processing, a persistent
status of the message is updated by the Messaging System. A log version with processing
step SC (see below) is added in case the interface (action) of the log version is different
compared to the final interface of the message. The logged messages are visible in PI
overview monitoring.

Configuring Message Logging in Case of Errors

Setting 6 ( Only synchronous error messages are logged) for property xiadapter.logger.conf
only covers behavior after steps BI, MS and AM.

To activate logging in case of errors in any case, you can do the following:

1. Start SAP Net Weaver Administrator from the following page: http ://< host> :< port>.
2. Choose SAP Net Weaver Administrator.
3. Choose (tab) Configuration Infrastructure Java System Properties .
4. In tab Services search for XPI Service: Messaging System.
5. On the Properties tab (under Extended Details) search for
messaging.system.statusLoggerConf.
6. To specify message logging behavior, choose Modify , and in field Enter Custom
Values enter the corresponding value according to the following syntax:

<Log state>, <content handling>

As log state, you can specify one of the following values:

Value Description
Error Log message in case of errors.
None No logging of messages

To specify the handling of business content, you use one of the following values:

Value Description
Full If logging is enabled, log message with business content.
Headers If logging is enabled, log message without business content.

As default, the value Error, Full is assigned, which means that messages are logged
including business content in case of errors.

The location SC is used for the logged message version. This log message is also
visible in PI overview monitoring.

Note:

Logging configuration for AAE pipeline is automatically propagated.

That means, for example: in case a log version was stored during pipeline processing
according to the configuration settings described above under Configuring Message Logging
at Specific Processing Steps, a log version with processing step SC (shortly referred to as log
version SC ) is not automatically stored. In this case, a log version SC is only stored if the
existing log version was created for a different interface (the payload is automatically hidden
then). This ensures consistency between overview monitoring and message monitoring
(persistent and in-memory).
Configuring the Enhanced Settings for Saving Messages:

Context:

For messages that are processed using this integration configuration, you can create settings
for saving message versions at runtime. In this way you specify the processing steps
according to which messages are to be stored on the Advanced Adapter Engine at runtime.

Note:

This option is of interest for administrators who monitor the running of integration scenarios
and have to take action in cases of errors.

There are two options for saving message versions:

 Staging: You can save message versions, edit them and restart the processing of the
changed message.
 Logging: You can save message versions for logging purposes. In this mode you only
have read-only access to the message version.

For more information, see the SAP Net Weaver Library under SAP Net Weaver Process
Integration Administrative Tasks Saving Message Versions .

Procedure:

1. Select the Enhanced Settings tab page.

2. Specify if you want to save message versions for staging or logging.

Irrespective of the communication mode, decide which option you want to make the
settings for:

o For asynchronous message processing you make the settings for staging or
logging.

Note

Note that staging can have a negative impact on performance. You should
therefore only employ staging when you need to Editor Restart functions.

o For synchronous message processing you make the settings for logging.

3. Specify if you want to configure staging or logging globally or scenario-specifically.

o Using Global Configuration:

 If you choose this option, those settings are effective that were configured using
Java system properties with SAP Net Weaver Administrator globally for all
scenarios. For more information, see the documentation as referenced above.

Note:

If you selected this option, you can skip the next step.

o Using Scenario-Specific Configuration:

If you select this option, the settings that you configured specially for this
integrated configuration are effective for staging or logging.

4. If you have selected the scenario-specific configuration, you must enter for staging or
logging the steps after which the message versions are to be saved. For each step you
can specify what is to happen with the message at runtime.

For staging you can select the following processing steps:

Processing Step Description

Message Preparation (Step The message version if saved after it was forwarded from
BI) the sender adapter to the messaging system.
Inbound XML Validation The message version is saved after the inbound XML
(Step VI) validation.
Receiver Determination The message version is saved after the receivers have been
(Step MS) determined for the message.
Mapping (Step AM) The message version is saved after the mapping has been
executed.
Outbound XML The message version is saved after the outbound XML
Validation (Step VO) validation.

For every step you have the following options to specify more accurately what is to
happen with the message at runtime:

o None

Message version not saved.

o Save on error

Message version saved when the following step has errors.

o Save

Message version is saved and the processing is continued with the next step.

For logging you can select the following processing steps:

Processing Step Description
Message Preparation The message version if saved after it was forwarded from
(Step BI) the sender adapter to the messaging system.
Receiver Determination The message version is saved after the receivers have been
(Step MS) determined for the message.
Mapping (Step AM) The message version is saved after the mapping has been
executed.

For every step you have the following options to specify more accurately what is to
happen with the message at runtime:

o None

Message version not saved.

o Log

Message version saved for logging.

o Log on error

Message version saved for logging in case of errors.

o Log without payload

Message version saved for logging. Payload cannot be displayed.

o Log without payload on error

Message version saved for logging in case of errors. Payload cannot be

displayed.

Note:

You can combine the selection of multiple processing steps both for staging and for
logging.

For more information on the processing steps, see the documentation specified above.
The objects in the Integration Directory are categorized as follows:

1. Collaboration Profile

 Party
 Business Component
 Communication Channel
 Process Component

2. Collaboration Agreement

 Sender Agreement
 Receiver Agreement
 Direct Connection
 Integrated Configuration

3. Configuration Objects

 Receiver Determination
 Receiver Rule
 Interface Determination
 Value Mapping Group

4. Administration

 Configuration Scenario
 Alert Rule
 Folder
 Change List