SAP XI / PI Administrators’ Guide

All versions

July 23, 2013

Table of Contents

1 General 3

2 Architectural Overview 4
2.1 Basic Architecture 4

2.2 Duplicate Check (Message ID Store) 5

2.3 Recovery Mechanism 5

3 System Resources 7
3.1 Database 7

3.2 File System 10

3.3 Network 11

4 Runtime Monitoring 12
4.1 SEEBURGER Workbench 12

4.2 SAP Monitoring 13

4.3 Recurring Tasks 14

5 Troubleshooting 15
5.1 Known Error Messages 15

5.1.1 com.sap.engine.services.dbpool.exceptions.BaseSQLException: Cannot change

transaction isolation during JTA transaction and when the connection is shared. 15

SAP XI / PI Administrators’ Guide 1

 5.2 Deployment Issues 15

5.2.1 javax.naming.NameAlreadyBoundException: Object with name SeeXI<Adapter> is

already bound. 15

Copyright (c) 2013 SEEBURGER AG (http://www.seeburger.de). All rights reserved.

If (registered or pending) trademarks are named in this document, the rights of the respective
proprietors apply.
Note: False configuration and/or improper use of communication components may cause high costs.
Also consider configuration changes initiated by your telecommunication provider. SEEBURGER is
not liable for related additional costs.
Note: The information in this document is proprietary to SEEBURGER. No part of this document
may be reproduced, copied, or transmitted in any form or purpose without the express prior written
permission of SEEBURGER AG.
Note: We expressly declare that the document "SEEBURGER Legal Information" (delivered also
with your BIS installation media) is part of this documentation.

SAP XI / PI Administrators’ Guide 2

1 General

This document aims to be an overview of the SEEBURGER SAP XI / PI solutions targeted at system
administrators. It should help them understanding the parts of the system involved when using
SEEBURGER solutions and what needs to be monitored to keep the system up and running.
Additionally, it gives some help what needs to be considered when moving or migrating a system.

Note: This document does not cover administration or migration tasks for
SEEBURGER Professional Message Tracking (MT) or SEEBURGER Portal.
Please refer to corresponding manuals or involve SEEBURGER support desk or
consulting.

Note: Information in this document is a "look behind the curtain". Keep this in mind,
as things might change between releases or even between patches in order to add
new features or fix existing bugs. We try our best to keep this document up-to-date,
so check for changes in the document in case of upgrades.

SAP XI / PI Administrators’ Guide 3

2 Architectural Overview

As the SEEBURGER solutions cover a wide range of different EDI protocols and message types
which result in lots of different business scenarios, it is hard to give a concrete architectural overview.
Nevertheless there are a few concepts which are similar between all SEEBURGER solutions. One
example for that is the SEEBURGER recovery mechanism which is used by all SEEBURGER
adapters and a few modules as well.
This topic only explains the general behavior of the specific concepts. In the next topic System
Resources (page 7) the used system resources (like database tables or file system paths) are
listed. This is due to the fact that while the concepts remain relatively stable, the concrete files, paths,
tables, etc. might change more frequently.

2.1 Basic Architecture

Although you might have bought a single SEEBURGER solution, the solution often consists of several
components interacting with different parts of an SAP system. Therefore in order to monitor and
administrate SEEBURGER solutions, you should understand the basic principles of an XI/PI.
The following list is a brief (and by no means complete) range of topics you might want to familiarize
yourself with:

• The Integration Engine

• The Adapter Engine
• The Messaging System
• What is part of the ABAP stack, what is part of the JAVA stack?
• What is a system, an instance, a server process, server node and which resources do they use?
Which resources do they share and which not? Which effect might that have?
• Monitoring and configuration of the different JAVA thread pools
• Different queues and dispatching mechanisms within the XI / PI runtime
• The concept communication channels, sender / receiver agreements, etc.

SAP XI / PI Administrators’ Guide 4

In case a system stops working you will likely need to check various parts of the system and therefore
it is very helpful to have a complete overview of the system.

2.2 Duplicate Check (Message ID Store)

EDI message protocols usually have some sort of mechanism to acknowledge messages (either
directly in the channel in which the original message is received, or via a separate connection between
the two business parties. Additionally, there is the need to check if a specific message has already
been sent (or received). This is where the SEEBURGER Message ID store comes into play.
Every SEEBURGER adapter stores information about every sent or received message within a
database table. This table can be inspected via the SEEBURGER workbench | Message Monitor.
Information in this table is used to:

• Correlate reports and messages

• Keep track of sent and received messages (to prevent duplicates)
• Report errors in case of sent messages not being acknowledged in time (usually there is a timeout
specified in the corresponding communication channel).

Additionally the Message ID store is also used to correlate external IDs (specified in the EDI message
protocol) with the XI MessageID which is used by the PI system to identify transactions.
The Message ID store has a reorganization mechanism in place which per default removes entries in
a final state after 7 days. The preservation time is configurable via the managed connection factory
properties of the corresponding adapter.

2.3 Recovery Mechanism

In some cases (for example when receiving files via HTTP based message protocols or polling
mailboxes) SEEBURGER solutions need to persist the incoming data prior to sending the messages
to the PI messaging system in order to prevent data loss. This is due to the architectural concept
of PI systems where the first persistence step is performed after the incoming message has been
run trough the sender communication channel, including all modules which are configured in such
a channel. Especially these modules are not within control of the adapter and therefore can cause
failures.
Therefore SEEBURGER adapters first persist the incoming messages within the SEEBURGER
recovery and after that send them to the PI system (via a sender communication channel).
In order to reduce memory consumption when receiving large files or messages, SEEBURGER uses
a temporary file to store the contents to. Additionally there is a second file (from now on referred to
as job file) which stores relevant meta data for the incoming message (as for example the party from
which that particular file has been received or the mailbox which has been involved, etc.). In case
the received data is less than 1MB, the content of the message is stored within the job file and the
temporary file for the content is omitted.
Some adapters choose to use more than one save point throughout the process of receiving a
message (e.g. save point one after the message is downloaded from the mailbox and a second

SAP XI / PI Administrators’ Guide 5

save point after the receiving has been acknowledged to the mailbox). These save points are called
milestones.
An overview of the messages which are currently stored within the SEEBURGER recovery can be
found in the SEEBURGER workbench | Recovery Monitor. Keep in mind, that there are recover jobs
for every message which is received, even if they are processed just fine.
In case a message fails (either through a general system error like an OutOfMemory situation on
the Java stack, or a general file system error) the SEEBURGER recovery mechanism triggers the
reprocessing of the failed messages. Recover jobs are retried 20 times before they get marked as Max
Retry Reached. Nevertheless it is possible to restart the retry process again.
To allow faster search operations on all existing recover jobs, some of the information contained in
the recover job file are also stored in the database. The SEEBURGER workbench | Recovery Monitor
displays only the contents of that table. If for some reason the elements in the table seem to be out
of sync with the recover jobs stored in the file system, please contact the SEEBURGER support desk
which has means to re-import jobs into the database table.

Note: All relevant information is stored within the recover job file. In case of missing
entries in the table no data loss has occurred if the job file and its referenced
temporary files still exist on file system!

SAP XI / PI Administrators’ Guide 6

3 System Resources

This topic provides a quick overview about where relevant data for SEEBURGER adapters and
modules is stored. In case you try to move or migrate a PI system, ensure to sync all of these contents
(either by means of the SAP migration tool, or manually using operating system utilities).
For a more detailed explanation what is stored in the respective places either have a look into the
previous topic (for general concepts applicable to all SEEBURGER solutions) or in the corresponding
adapter or module documentation.

3.1 Database
All of the configuration data and most of the runtime data are stored within the database, please refer
to the topic Architectural Overview (page 4) for a more detailed explanation about how all of these
elements play together.
SEEBURGER uses the following tables within the standard PI database scheme. Keep in mind that
you will only have tables applicable to your set of solutions which are installed on the system. The
table contains information about the solution(s) which the tables belong to. The category indicates the
type of data stored in this table (either runtime or configuration).

Note: All tables start with the prefix SEE_. In case you find a table which is prefixed
with SEE_ it is most likely that this table is simply missing here. Handle it the same
way you do with the other tables listed here (with regard to migrating systems,
monitoring table size, etc.).

Table Name Category Since Applicable Solutions

SEE_ADDRBOOKAUT configuration <1.7 Payment
SEE_ADDRBOOKP7 configuration <1.7 Aerospace_Defence,
Automotive, Chemicals,
CPG, GenericEDI,

SAP XI / PI Administrators’ Guide 7

Table Name Category Since Applicable Solutions
Hightech, Paper,
Payment, Retail,
X400VAN, Utility
SEE_BPATTACH runtime 2.2 all
SEE_DBPROPSTORE configuration <1.7 all
SEE_DSIG_PARTNER configuration <1.7 DSIG for Utility,
eInvoicing
SEE_DSIG_PROP configuration <1.7 DSIG for Utility,
eInvoicing
SEE_DSIG_SERVER configuration <1.7 DSIG for Utility,
eInvoicing
SEE_DSIG_SIGNER configuration <1.7 DSIG for Utility,
eInvoicing
SEE_ERRORMONITO runtime 2.2 all
R
SEE_MSGIDSTOREAS runtime <1.7 AS2
2
SEE_MSGIDSTOREAU runtime <1.7 Payment
T
SEE_MSGIDSTOREEB runtime <1.7 EbXML, Papinet
XMLC
SEE_MSGIDSTOREFT runtime <1.7 Aerospace_Defence,
P Automotive, Chemicals,
CPG, GenericEDI,
Paper, Payment,
Pharmaceutical, Retail,
X400VAN
SEE_MSGIDSTOREHF runtime <1.7 HostFTP
TP
SEE_MSGIDSTOREO runtime <1.7 Automotive, CPG,
FTP GenericEDI, OFTP,
Payment, Retail,
X400VAN, Utility
SEE_MSGIDSTOREP7 runtime <1.7 Aerospace_Defence,
Automotive, Chemicals,
CPG, GenericEDI,
Hightech, Paper,
Payment, Retail,
X400VAN, Utility
SEE_MSGIDSTORESF runtime <1.7 SFTP
TP

SAP XI / PI Administrators’ Guide 8

Table Name Category Since Applicable Solutions
SEE_MSGIDSTORESP runtime <1.7 all
LITTER
SEE_RECOVERINSTR configuration 1.8 all
EL
SEE_RECOVERYJOB runtime 1.8 all
SEE_RECOVERYTIME configuration 1.8 all
R
SEE_RMASSIGNMENT configuration <1.7 all
SEE_RMDEPENDENC configuration <1.7 all
Y
SEE_RMISDNDETAILS configuration <1.7 all
SEE_RMRESERVATIO runtime <1.7 all
N
SEE_RMRESOURCE configuration <1.7 all
SEE_SPLITTERCONF configuration <1.7 all
SEE_TEDISECAUTAC runtime <1.7 Payment
K
SEE_TEDISECCORRE runtime <1.7 Payment
LA
SEE_TEDISECINTER runtime <1.7 Payment
SEE_TEDISECMESSA runtime <1.7 Payment
GE
SEE_TPERMCOUNTE configuration <1.7 all
RS
SEE_TPERMLOBS configuration <1.7 all
SEE_TPERMVARIABL configuration <1.7 all
ES
All tables starting with SEE_MSGIDSTORE relate to the above mentioned concept of duplicate
checking and correlating the PI internal XI MessageID with the respective external ID of the EDI
message protocol.
The tables which start with SEE_RECOVER belong to the SEEBURGER recovery mechanism. Keep
in mind, that in addition to the tables there are also recover jobs on the file system, which are required
to correctly process recover jobs.
Tables which are in the category configuration are all accessible from the SEEBURGER workbench.
Additionally, they all have an import/export functionality which allows you to download and backup
the configuration and then reapply it to a new or migrated system. SEEBURGER generally advices
customers to use database means to migrate tables, but if these cannot be used due to various
reasons, it is possible to use that import / export functionality. In case you have large amounts of data
it might take some time to prepare the export, and that in the end can cause HTTP timeouts. In such

SAP XI / PI Administrators’ Guide 9

cases the HTTP timeout parameter within the SAP WebAS or SAP Internet Communication Manager
need to be increased. Refer to the corresponding SAP documentation for details.

3.2 File System

SEEBURGER uses a few places within the file system to store information. The root directories are
located at:

• /usr/sap/<SAP system ID>/SYS/global/seeburger/

• /usr/sap/<SAP system ID>/<Java instance name>/j2ee/cluster/server<x>/seeburger
• /usr/sap/<SAP system ID>/<Java instance name>/j2ee/cluster/server<x>/Seeburger (only on
UNIX systems)
• /usr/sap/<SAP system ID>/<Java instance name>/j2ee/cluster/server<x>/SeeConfig

It is necessary, that the SYS/global directory is shared between all cluster nodes (regardless
whether the nodes are located on one hardware or distributed between several machines. In UNIX
environments this is also requested by the SAP documentation. Unfortunately, this is not required
for SAP systems on Windows. Nevertheless in order for the cluster functionality within SEEBURGER
solutions (e.g. handover of recover jobs if one node goes down) this is a strict requirement. This
directory is crucial for the work of the SEEBURGER solutions so it needs to be maintained when
moving or migrating systems.
Regarding the server<x>/…/SeeConfig directories under the root directories mentioned above,
each adapter generates a unique ID for each node it runs on. This information is persisted in these
directories, and therefore it is recommended to move these directories along if you choose to migrate
your system. If not, a new ID will be generated, which might have some effects on the SEEBURGER
Resource Management (e.g. hanging resources).
In large part server<x>/seeburger contains runtime data, for example the transmission data dumps (if
activated in the managed connection factory properties), but it may also contain other persisted data
which has been processed on that node, especially in versions before 1.8 (e.g. in previous versions
the recover jobs have been located there.) It is recommended to include this directory when migrating
system.

Note: Via the Java system property com.seeburger.xi.global.root it is possible to

reconfigure the file system paths needed for the recovery mechanism. So it might
be possible that another directory needs to be added to the above list if such a
configuration is in place.

SAP XI / PI Administrators’ Guide 10

3.3 Network
Also worth mentioning for migrating or moving systems is network configuration. This section gives a
quick overview where SEEBURGER adapters and modules refer to network configurations (either IP
addresses or DNS names).
Obviously, a lot of EDI protocols communicate over TCP based networks and therefore refer to their
endpoints either via IP addresses or DNS names. So check the communication channel configurations
for these and fix them accordingly.
In addition to the local configuration there also exist a lot of operating system configuration options
which might affect a smooth migration. Firewalls and routers are an additional source of many errors.
Special care needs to be taken for systems which have multiple IP addresses assigned to one network
card, or which contain multiple network interfaces.
If host name changes, you have to consider that the host name might be part of used security
certificates, or the host name might be used for SEEBURGER resource assignments in SEEBURGER
Resource Management, so maybe those parts have to be updated as well.

SAP XI / PI Administrators’ Guide 11

4 Runtime Monitoring

This topic is intended to give administrators are quick overview about the different monitoring facilities
of the SEEBURGER solutions.

4.1 SEEBURGER Workbench

All SEEBURGER monitors are available through the SEEBURGER workbench (reachable via http://<h
ostname>:<port>/seeburger of your PI system). Access is granted to everyone by default, but this can
be restricted via the NetWeaver administrator’s identity management. Check the SAP documentation
on how to restrict access to web applications and the SEEBURGER documentation for the actions
which can be granted.

Message Monitor

As explained in the architectural overview, the SEEBURGER Message Monitor can be used to monitor
the contents of the Message ID store.
It also contains information about failing incoming messages which unfortunately are only visible within
the SAP monitoring for a limited amount of time (only a fixed amount of message is visible within the
SAP communication channel monitoring, therefore messages quickly "rotate" out of this monitors).
With the help of the Message Monitor it is possible to have a look at errors which happened in a
specific time frame.

Recovery Monitor

The Recovery Monitor allows you to view the current active recover jobs. As already noted in the
architectural overview topic of this document, every message being received by a SEEBURGER
adapter results in a recover job. This means on a busy system, there are always a lot of jobs visible in
the monitor. To narrow the search down, use the time filtering capabilities of the monitor.
You should look for recover jobs which have a retry count greater one. These indicate a processing
error (either temporary, due to various runtime effects like a timeout while acquiring a database
connection, or permanent due to a configuration issue).

SAP XI / PI Administrators’ Guide 12

Resource Management

If you are using the SEEBURGER resource management (e.g. when using OFTP over ISDN or
accessing different VAN boxes which allow only a limited number of concurrent logins) you can watch
the current active resources and their reservations via the reservation monitor.
One reservation should always be visible, which is the RecoverTimer_DEFAULT. This reservation is
used to ensure, that only one node in the cluster is responsible for dispatching recover jobs in case
they fail in the first run and need to be retried. If you do not have such a reservation, chances are high,
that the recovery mechanism is not working properly.

System Status

The SEEBURGER system status front-end is an overview of important configuration parameters to

the SEEBURGER solutions. It also provides means to export all relevant data within a zip file for easy
exchange with the SEEBURGER support. It helps a lot to provide you with fast responses to your
support inquiries.

Note: The system status is currently not cluster-aware. That means it displays the
"view" of the current cluster node. In case of database summaries this of course is
applicable for the complete instance, but for example Java system properties might
be different across server nodes.

4.2 SAP Monitoring

In addition to the SEEBURGER monitors, SAP offers a lot of other monitoring tools to check the health
of the system or to determine where any why messages seem to be stuck. The following list gives you
a quick overview of some monitors which might be interesting with regard to EDI communication.

• SAP GUI transaction SXMB_MONI – XI message processing within Integration Engine/ABAP

Stack
• SAP GUI transaction SMQ1 / SMQ2 – Monitoring of the RFC queues in Integration Engine
• Runtime Workbench → Communication Channel Monitoring
• Runtime Workbench → Adapter Log (Channel-Independent)
• Runtime Workbench → Engine Status
• NetWeaver Administrator and its monitoring features

SAP XI / PI Administrators’ Guide 13

4.3 Recurring Tasks
This is a recommended, but by no means complete list of things to watch on a regularly basis. These
should be fairly easy to automate via every system monitoring tools you might use (e.g. Nagios or
Cacti). It is strongly recommended to at least check them once in a while.

• Check the amount of entries in SEE_RECOVERYJOB. The entry count should reflect your actual
message throughput. In case there are messages stuck an administrator needs to check them
manually, and should either reprocess the messages or delete them, if they are no longer needed.
• Check that the entries in SEE_RECOVERYJOB are in sync with the job files on the file system.
Job files are located at …/SYS/global/seeburger/recovery (from version 1.8 on) and match the file
name pattern *.job.
• Check the amount of entries in the table SEE_MSGIDSTORE*. The amount should reflect your
message throughput in the preservation time frame configured. In case the number increases
further analysis is required. This might coincide with an increasing number of recover jobs in
case there is a general issue with the system (e.g. due to a configuration issue some types of
messages do not get processed correctly).
• In case the resource management is used, check the reservation monitor (or the
SEE_RMRESERVATION table) if entries get stuck. The reservation date is visible and should
not exceed a few minutes. An exception to this is of course the RecoverTimer_DEFAULT which
usually exists as long as the corresponding server node stays alive.
Additionally keep in mind, that some scenarios (e.g. if you have a constant stream of OFTP
messages, which are all transmitted via the same ISDN line) a reservation can last several hours
or even longer. Nevertheless, as soon as no current message requires a specific resource that
reservation should get cleaned up automatically by adapter.
• From version 2.2 on the table SEE_BPATTACH should also be checked to roughly match the
message throughput within the preservation time frame.
• Monitor the disk usage of the SEEBURGER file system paths which are used. Keep in mind, that
e.g. the transmission data dump directories are not cleaned automatically, and therefore may
increase over time.
• The SEEBURGER BIC module might write log files of the conversions in case of an error (can be
configured, check the BIC documentation). This might also be a source of ever increasing disk
usage. The attachment logs are stored under server<x>/seeburger/attachmentlog.

SAP XI / PI Administrators’ Guide 14

5 Troubleshooting

5.1 Known Error Messages

5.1.1
com.sap.engine.services.dbpool.exceptions.BaseSQLException:
Cannot change transaction isolation during JTA transaction and
when the connection is shared.
The above noted exception can occur due to SEEBURGER software trying to change the transaction
isolation level on a database connection which is maintained by the application server. If the stack
trace contains com.seeburger.recover.db.DBAccessHandler the error can safely be ignored.
Unfortunately this exception is generated by SAP libraries and SEEBURGER is not able to prevent
these exceptions from being logged.

5.2 Deployment Issues

5.2.1 javax.naming.NameAlreadyBoundException: Object with name

SeeXI<Adapter> is already bound.
This exception happens if an adapter could not be started correctly the first time and a subsequent
start or deployment occurs. Unfortunately the SAP adapter framework does not always cleanup
resources if an adapter fails to start.

SAP XI / PI Administrators’ Guide 15

 Note: This is a subsequent error. In order for SEEBURGER to analyze the root
cause, the real exception from the first failed start is needed.

In case the startup-failure was due to a temporary problem (e.g database connection was broken) a
server restart is enough to fix the issue. In case it is a permanent error, the first start of the adapter
after the server restart will contain the real error. The logs covering that first start are needed by the
SEEBURGER support team to find the root cause.

SAP XI / PI Administrators’ Guide 16