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 3.1 Database

7 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 5.1 Known Error Messages

15 15

5.1.1 com.sap.engine.services.dbpool.exceptions.BaseSQLException: Cannot change transaction isolation during JTA transaction and when the connection is shared.

SAP XI / PI Administrators’ Guide

15

1

5.2 Deployment Issues

15

5.2.1 javax.naming.NameAlreadyBoundException: Object with name SeeXI 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