SBC SAPAdapterGuide 481

SAP Business Connector
SAP Adapter Guide
SA P SY S TE M
Release 4.8.1
SAP® SE  Dietmar-Hopp-Allee  D-69190 Walldorf

SAP SE SAP Business Connector SAP Adapter Guide
Copyright
©Copyright 2020 SAP SE. All rights reserved.
No part of this description of functions may be reproduced or transmitted in any form or for any
purpose without the express permission of SAP SE. The information contained herein may be
changed without prior notice.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
Microsoft®, WINDOWS® and EXCEL®, NT® and SQL-Server® are registered
trademarks of Microsoft Corporation.
IBM®, OS/2®, DB2/6000®, AIX®, OS/400® and AS/400® are registered trademarks of IBM
Corporation.
OSF/Motif® is a registered trademark of Open Software Foundation.
ORACLE® is a registered trademark of ORACLE Corporation, California, USA.
webMethods® is a registered trademark of webMethods Incorporated, Virginia, USA.
INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
UNIX® and X/Open® are registered trademarks of SCO Santa Cruz Operation.
SAP®, R/2®, R/3®, RIVA®, ABAP/4®, SAPaccess®, SAPmail®, SAPoffice®, SAP-EDI®, SAP
Business Workflow®, SAP EarlyWatch®, SAP ArchiveLink®, R/3 Retail®, ALE/WEB®,
SAPTRONIC® are registered trademarks of SAP SE.
All rights reserved.
SAP Business Connector ii

Typographical Conventions
Type Style Description
Interface Text Words or characters that appear on the screen. This includes field
names, screen titles, pushbuttons, menu names, and menu options.
Document Title Cross-references to other documentation.
User Entry Words and characters that you enter exactly as they appear in the
documentation.
<Variable User Variable user entry. Pointed brackets indicate that you replace these
Entry> words and characters with appropriate entries.
NAME Names of elements in the SAP System. These include program

names, transaction codes, table names, ABAP key words, file
names, and directories.
Name File names, path names, program names, user names, parameters,
file contents and operating system output.
KEY Keys on the keyboard. These include the function keys, e.g. F2, or
the ENTER key.
Icon Description
A note. Notes contain important information, e.g. exceptions or

special cases.
An example. Examples illustrate complex procedures or the syntax

for user entries.
A caution. Cautions help users avoid errors which can, for example,
lead to loss of data.
Hints and Tips.
SAP Business Connector iii

Contents
Chapter 1: Introduction ............................................................................................1-1

Welcome! ...............................................................................................................1-2
Related Documentation .........................................................................................1-2
Chapter 2: Product Overview ...................................................................................2-1
What is the SAP Business Connector? ................................................................2-2
Functional Highlights ............................................................................................2-2
Complete SAP System Integration ......................................................................2-3
Integrating SAP Systems over the Internet..........................................................2-3
Routing IDocs, RFCs and BAPIs.........................................................................2-3
Support for IDoc- and RFC-XML .........................................................................2-4
Support of BizTalk XML envelopes for BAPI and RFC calls.................................2-4
Support of Unified Error Handling of BAPIs and RFCs on XML Level ..................2-4
Built-in BAPI Tools..............................................................................................2-5
Message Store ...................................................................................................2-5
Architecture and Components..............................................................................2-6
Basic Concepts ..................................................................................................2-6
Invoking Business Logic.......................................................................................2-8
Routing Messages through the Partner Manager ................................................2-9
Chapter 3: Calling an SAP System from SAP BC Services.....................................3-1
Overview ................................................................................................................3-2
General Settings ....................................................................................................3-2
Defining SAP Servers ............................................................................................3-4
Testing the Connection to SAP Servers ............................................................3-12
Testing that the SAP Server will execute an RFM .............................................3-14
Creating an SAP BC Service that Executes an RFM ..........................................3-16
Creating an Outbound Map...............................................................................3-17
Searching for maps without reference ...............................................................3-18
Using optional tables in Outbound Maps ...........................................................3-19
Testing the Function Module .............................................................................3-21
Testing that the SAP Server will Execute an RFC-XML .....................................3-22
Posting an RFC-XML Document from an HTTP Client ......................................3-22
Creating an SAP BC Service that Executes a BAPI ...........................................3-23
SAP Business Connector iv

Starting to Browse ............................................................................................3-23

Displaying a List of Business Objects in the System..........................................3-24
Displaying a Business Object............................................................................3-25
Displaying a BAPI .............................................................................................3-26
Displaying a BAPI Parameter............................................................................3-27
Displaying a Key Field ......................................................................................3-27
Generating XML Calls for a BAPI ......................................................................3-28
Posting a BAPI from an HTTP client .................................................................3-30
Chapter 4: Calling SAP BC Services from an SAP System.....................................4-1
Overview ................................................................................................................4-2
Creating an RFC Destination on an SAP System .................................................4-2
Register SAP Business Connector as an RFC Destination ..................................4-2
Configuring an RFC Listener in SAP Business Connector Server......................4-7
Managing RFC Trace Information .......................................................................4-9
Testing the RFC Listener ....................................................................................4-9
Managing RFC Trace Information .....................................................................4-12
Testing the WebSocket RFC Listener ...............................................................4-12
Monitoring information for RFC Listeners .........................................................4-14
Viewing and deleting RFC Trace Files and SAP Log Files.................................4-14
Performance output information in the SAP Log File .........................................4-14
jARM (Java Application Responsetime Measurement) ......................................4-16
Monitoring Information via Passport and DSR ..................................................4-18
Mapping Inbound RFCs to SAP BC Services .....................................................4-20
Creating a Function Module in an SAP System .................................................4-20
Creating an Inbound Map .................................................................................4-21
Testing the Product Retrieval Function .............................................................4-23
Sending an RFC from an SAP System to SAP BC .............................................4-24
The SBCHEADER Table ..................................................................................4-25
Generating a record for a structure ...................................................................4-29
Working with different code pages .....................................................................4-30
To receive data from http, ftp, email or file ........................................................4-30
To send out data via http, ftp, email or save it to file ..........................................4-30
To encode data from SAP Systems ..................................................................4-30
Chapter 5: The Partner Manager ..............................................................................5-1
Introduction ...........................................................................................................5-2
Overview of the Partner Manager .........................................................................5-2
SAP Business Connector v

Components of a Routing Rule ...........................................................................5-3

Using Wildcards as Routing Criteria ....................................................................5-4
Routing Rule Precedence ...................................................................................5-5
Establishing Routing Rules ..................................................................................5-8
When a Routing Rule Is Not Defined ..................................................................5-15
Managing Routing Rules .....................................................................................5-16
Displaying Routing Rules ..................................................................................5-16
Updating Routing Rules ....................................................................................5-16
Disabling Routing Rules ...................................................................................5-17
Deleting Routing Rules .....................................................................................5-17
Editing a Routing Service ...................................................................................5-18
Guidelines to Follow When Editing a Routing Service .......................................5-18
Updating the Flow Associated with a Routing Rule...........................................5-18
Example of Updating a Flow for FTP or Email Transport ...................................5-19
Example of Digitally Signing a Message............................................................5-20
Managing Transactions in the Message Store ...................................................5-20
Viewing Transactions in the Message Store ......................................................5-21
Deleting Transactions from the Message Store .................................................5-24
Automatic Cleanup of the Message Store .........................................................5-25
Configuration Parameters for the Partner Manager...........................................5-25
Chapter 6: Setting up Routing for BAPIs .................................................................6-1
Inbound Call to an SAP System ............................................................................6-2
Setting up the SAP Business Connector and the BAPI Transport ........................6-2
Posting BAPI-based XML to the SAP Business Connector ..................................6-3
Posting RFC Based IFR-compatible XML Messages...........................................6-4
Transaction Control ............................................................................................6-4
BAPI XML Transaction Commit...........................................................................6-4
Synchronous Calls..............................................................................................6-5
Asynchronous Calls to SAP Systems ..................................................................6-6
Outbound Call from an SAP System ....................................................................6-8
Overview ............................................................................................................6-8
Setting Up Routing Rules for the XML Transport .................................................6-9
RFC Based XML Messages Using IFR Format .................................................6-11
Dynamic Routing Using the XML Transport.......................................................6-11
Example: Calling a BAPI Synchronously from an SAP System ..........................6-12
Example: Calling a BAPI Asynchronously from an SAP System ........................6-15
SAP Business Connector vi

Chapter 7: Routing IDocs and XML messages to the Partner Manager .................7-1
Introduction ...........................................................................................................7-2
Sending IDocs with ALE from an SAP System to SAP BC ..................................7-2
Posting IDoc- and RFC-XML (XRFC) Documents .................................................7-5
Posting an IDoc-XML Document from an HTTP Client ........................................7-5
Posting an IDoc via FTP .....................................................................................7-6
Posting an IDoc in an email message .................................................................7-6
Posting an IDoc from a Web Browser .................................................................7-7
Transmitting IDocs between two Business Connectors......................................7-7
Posting arbitrary XML documents ........................................................................7-8
Mapping IDocs to Other Formats........................................................................7-10
Creating a Routing Rule that points to a Flow Service .......................................7-11
Obtaining a Record Definition for Your IDoc ......................................................7-13
Mapping the data in an IDoc .............................................................................7-18
Pre-Routing Mechanisms for content-based routing with IDocs ......................7-23
Using the ALE Monitoring Features via the SAP BC .........................................7-26
Introduction ......................................................................................................7-26
IDoc Trace........................................................................................................7-27
Status Update via ALEAUD IDoc ......................................................................7-28
Status Update via SYSTAT01 IDoc...................................................................7-29
Improving the Performance of the Partner Manager..........................................7-31
Chapter 8: Coding Client Applications and Services ..............................................8-1
Overview ................................................................................................................8-2
Invoking RFCs from SAP Business Connector Server ........................................8-3
Calling SAP Services from Java Services ...........................................................8-3
Receiving IDocs from an SAP System..................................................................8-4
Accessing and Modifying Fields in IDocs ............................................................8-4
Converting an IDoc to XML .................................................................................8-5
Traversing all segments and attributes of an IDoc ...............................................8-5
Constructing an IDoc with the SAP Java IDoc Library ........................................8-6
Sending IDocs to an SAP System.........................................................................8-8
Transaction Features for HTTP and SAP-XML .....................................................8-8
Chapter 9: Security ...................................................................................................9-1
Product Availability ...............................................................................................9-2
SAP BC Configuration...........................................................................................9-2
SAP Business Connector Developer ...................................................................9-2
SAP Business Connector vii

Java Client Code ................................................................................................9-2

Initializing the Security Settings in the SAP BC...................................................9-3
User Authentication between SAP BC and an SAP System ................................9-3
Authentication through Username and Password ................................................9-3
Authentication through X.509 Certificate .............................................................9-3
Authentication when SAP BC acts as RFC-Server ..............................................9-7
Using SAP BC with the SAP Cryptographic Library for SNC................................9-8
Authorization Profiles for the SAP Logon User ..................................................9-10
Authorization Configuration in the SAP Environment .......................................9-10
Installing SAP BC according to your Security Policy ........................................9-10
References ...........................................................................................................9-11
Chapter 10: Managing the DDIC Cache..................................................................10-12
Data Dictionary Cache (DDIC Cache) ...............................................................10-13
Viewing Information in the DDIC Cache ...........................................................10-13
Removing Information from the DDIC Cache ...................................................10-16
Appendix A Package Contents.................................................................................. A-1
Package Layout .................................................................................................... A-2
Appendix B Server Configuration ............................................................................. B-1
server.cnf .............................................................................................................. B-2
Appendix C Representation of ABAP Types in SAP BC .......................................... C-1
Appendix D SAP Business Connector API ............................................................... D-1
SAP Client Services ............................................................................................. D-2
pub.sap.client:connect ....................................................................................... D-2
pub.sap.client:lockSession................................................................................. D-3
pub.sap.client:releaseSession ........................................................................... D-4
pub.sap.client:invoke ......................................................................................... D-5
pub.sap.client:invokeTransaction ....................................................................... D-6
pub.sap.client:createTID .................................................................................... D-7
pub.sap.client:confirmTID .................................................................................. D-7
pub.sap.client:getAttributes................................................................................ D-8
pub.sap.client:getFunctionInterface.................................................................. D-10
pub.sap.client:getStructureDefinition ................................................................ D-11
pub.sap.client:sendIDoc .................................................................................. D-12
pub.sap.client:ping........................................................................................... D-13
XRFC Services .................................................................................................... D-14
pub.sap.rfc:encode .......................................................................................... D-14
SAP Business Connector viii

pub.sap.rfc:decode .......................................................................................... D-15

pub.sap.rfc:createTemplate ............................................................................. D-15
IDoc Services...................................................................................................... D-17
pub.sap.idoc:encodeSDATA ............................................................................ D-17
pub.sap.idoc:decodeSDATA ............................................................................ D-18
pub.sap.idoc:transformFlatToHierarchy............................................................ D-18
pub.sap.idoc:transformHierarchyToFlat............................................................ D-19
pub.sap.idoc.routing:registerService ................................................................ D-20
pub.sap.idoc.routing:unregisterService ............................................................ D-20
pub.sap.idoc:encodeString .............................................................................. D-21
pub.sap.idoc:decodeString .............................................................................. D-21
pub.sap.idoc:iDocToRecord ............................................................................. D-22
pub.sap.idoc:recordToIDoc .............................................................................. D-22
pub.sap.idoc:iDocToTables ............................................................................. D-23
pub.sap.idoc:tablesToIDoc .............................................................................. D-23
IDoc-XML Services ............................................................................................. D-24
pub.sap.idoc:encode ....................................................................................... D-24
pub.sap.idoc:decode ....................................................................................... D-25
bXML Services .................................................................................................... D-26
pub.sap.bapi:encode ....................................................................................... D-26
pub.sap.bapi:decode ....................................................................................... D-27
pub.sap.bapi:createTemplate........................................................................... D-27
BAPI Services ..................................................................................................... D-28
pub.sap.bapi:commit........................................................................................ D-28
pub.sap.bapi:rollback ....................................................................................... D-29
Routing Rule Administration Services .............................................................. D-30
wm.PartnerMgr.gateway.admin:addRoutingRule .............................................. D-30
wm.PartnerMgr.gateway.admin:editRoutingRule .............................................. D-31
wm.PartnerMgr.gateway.admin:removeRoutingRule ........................................ D-32
wm.PartnerMgr.gateway.admin:disableRoutingRule ........................................ D-33
wm.PartnerMgr.gateway.admin:enableRoutingRule ......................................... D-33
wm.PartnerMgr.gateway.admin:listRoutingRule ............................................... D-33
wm.PartnerMgr.gateway.admin:getRoutingRule............................................... D-34
wm.PartnerMgr.gateway.admin:listTransports.................................................. D-35
Transaction Administration Services ................................................................ D-36
wm.PartnerMgr.xtn.admin:list........................................................................... D-36
SAP Business Connector ix

wm.PartnerMgr.xtn.admin:get .......................................................................... D-38

wm.PartnerMgr.xtn.admin:getMessage ............................................................ D-39
wm.PartnerMgr.xtn.admin:mapDocNumToTID ................................................. D-39
wm.PartnerMgr.xtn.admin:delete ..................................................................... D-39
wm.PartnerMgr.xtn.admin:deleteAll.................................................................. D-40
wm.PartnerMgr.xtn.admin:deleteSelection ....................................................... D-40
wm.PartnerMgr.xtn.archive:create ................................................................... D-40
wm.PartnerMgr.xtn.archive:restore .................................................................. D-42
wm.PartnerMgr.xtn.admin:shrinkStore ............................................................. D-42
Transport Services ............................................................................................. D-42
pub.sap.transport.ALE:InboundProcess ........................................................... D-43
pub.sap.transport.ALE:OutboundProcess ........................................................ D-43
wm.PartnerMgr.gateway.transport.B2B:InboundProcess.................................. D-45
wm.PartnerMgr.gateway.transport.B2B:OutboundProcess ............................... D-45
wm.PartnerMgr.gateway.transport.EmailTransport:OutboundProcess .............. D-47
wm.PartnerMgr.gateway.transport.FTPTransport:OutboundProcess ................ D-48
pub.sap. transport.RFC:InboundProcess....................................................... D-50
pub.sap.transport.RFC:OutboundProcess........................................................ D-50
pub.sap.transport.XML:InboundProcess .......................................................... D-51
pub.sap.transport.XML:OutboundProcess........................................................ D-52
pub.sap.transport.BAPI:InboundProcess.......................................................... D-54
pub.sap.transport.BAPI:OutboundProcess ....................................................... D-54
XSLT Services .................................................................................................... D-55
pub.sap.xslt.transformation:XSLTransformation ............................................... D-55
pub.sap.xslt.transformation:clearTemplatesCache ........................................... D-57
pub.sap.xslt.transformation:removeCachedTemplate ....................................... D-57
Demo Services.................................................................................................... D-57
sap.demo:handleIDocXMLPost........................................................................ D-57
sap.demo:handleRfcXMLPost.......................................................................... D-58
sap.demo:handlebXMLPost ............................................................................. D-58
sap.demo:writeSAPXMLFile ............................................................................ D-59
sap.demo:invokeBAPIReturningbXML ............................................................. D-59
Miscellaneous Services ..................................................................................... D-59
wm.PartnerMgr.gateway.runtime:confirmTID ................................................... D-59
wm.PartnerMgr.xtn.Sweeper:sweepTRX.......................................................... D-60
IDoc Java API ..................................................................................................... D-60
SAP Business Connector x

Appendix E List of deprecated services ................................................................. E-61

Appendix F INDEX .........................................................................................................2
SAP Business Connector xi

SAP AG
Chapter 1: Introduction
Welcome! .............................................................................. 1-2

Related Documentation.......................................................... 1-2

1-1
SAP AG
Welcome!
This guide describes how to install, configure, and develop applications for the SAP Business
Connector. It contains information for administrators who manage the system, and for application
developers who create applications that use the system.
To use this guide effectively, you should:
• Understand the basic concepts SAP Business Connector and XML.
• Have completed the tutorial in the SAP Business Connector Developers Guide or have a
general idea about how to perform basic tasks with the SAP BC Developer.
• Know how to create Flow Services and/or Java services.
• Be familiar with the set up and operation of the SAP Business Connector Server.
Related Documentation
The following documents are companions to this guide. Some documents are in PDF format and
others are in HTML.
Refer to this book… For…
SAP Business Connector Information about using the Server Administrator to configure, monitor, and
Administration Guide control the SAP Business Connector Server. This book is for server
administrators.
You will find this book at:
<sapbc>\Server\doc\SAPBCAdministrationGuide.pdf
SAP Business Connector Information about creating and testing SAP BC services and client
Developer Guide applications. This book is for application developers.
<sapbc>\Developer\doc\SAPBCDeveloperGuide.pdf
This guide is only available, when the SAP BC Developer is installed.
SAP Business Connector Information that orients you to SAP BC and shows you how to create a
Developer Tutorial simple application. It includes basic conceptual information about B2B.
This book is aimed at new users of SAP Business Connector.
<sapbc>\Developer\doc\SAPBCDeveloperTutorial.pdf
SAP Business Connector Information about the controls in the SAP BC Developer application
Developer Online Reference windows and step-by-step procedures describing how to perform tasks with
the SAP BC Developer.
You can access the online reference by clicking Help in an application
window or dialog box.
This reference is only available, when the SAP BC Developer is installed.
SAP Business Connector 1-2

SAP AG
Refer to this book… For…
SAP Business Connector This guide describes the built-in services provided with a standard
Built-In Services installation of SAP Business Connector and located in the WmPublic or
WmDB packages.
You will find this document at:
<sapbc>\Developer\doc\SAPBCBuiltInServices.pdf
Serialization of ABAP data in In depth information about how ABAP data is serialized in XML messages.
XML This serialization is used for RFC and BAPI parameters.
<sapbc>\Server\packages\SAP\doc\ABAPSerialization.h
tml
XML Format Specifications In depth information about how RFCs, BAPIs and IDocs are formatted in
XML.
You will find this guide at:
<sapbc>\Server\packages\SAP\doc\IFR-
XMLFormatSpec.pdf
RFC-XML Specification In depth information about the RFC-XML specifications

<sapbc>\Server\packages\SAP\doc\RFC_XML.html
SAP Business Connector In depth information about the IDoc Java classes.
IDoc Class Documentation
You will find this guide at:
<sapbc>\Server\packages\SAP\pub\doc\idoc30\index.ht
ml
SAP Business Connector Descriptions of the Java classes and built-in services you use to create
API Reference SAP BC services. This reference is for application developers who build
SAP BC services.
<sapbc>\Developer\doc\api\Java\index.html
Microsoft BizTalk Framework This add-on package introduces XML messages that are based on the
1.0a Microsoft Biztalk Framework. Further information on this framework and the
BizTalk Envelope XML envelope it defines can be found on the web site
Specifications http://www.biztalk.org
See also:
Independent Document <sapbc>\Server\packages\SAP\doc\BizTalkEnvelopeSpec
Specification .pdf

SAP AG
Chapter 2: Product Overview
What is the SAP Business Connector?........................................ 2-2

Functional Highlights .................................................................. 2-2
Architecture and Components..................................................... 2-6
Invoking Business Logic ............................................................. 2-8
Routing Messages through the Partner Manager ......................... 2-9

SAP AG
What is the SAP Business Connector?

The SAP Business Connector allows you to extend your business processes over the
Internet and integrate non-SAP products using open and non-proprietary technology.
The SAP Business Connector allows for bi-directional, real-time as well as asynchronous
communication to and from the SAP server. You can:
 Execute SAP’s implementation-independent BAPI methods, as they are described in the
Business Object Repository (BOR). BAPIs are stable, precisely-defined and well-documented
interfaces to SAP solutions, providing standardized access to SAP solutions on a semantic
level. You can quickly and easily create XML-based SAP BC services that execute a BAPI.
Applications within your organization can then invoke the SAP BC services to execute a
BAPI on the SAP server. Similarly, your business partners can make requests over the Internet
to invoke a service that executes a BAPI. The BAPI-interfaces provide a unified access to the
application-level functionality, independent of the type of call: Both synchronous as well as
asynchronous processing can be triggered by using these interfaces. Asynchronous processing
uses the ALE services inside the SAP System transparently for the client.
 Execute SAP Remote Function Calls (RFCs) from the SAP Business Connector
Server. You can access all SAP functionality that is available via RFC from SAP Business
Connector Server. External applications do not need to understand SAP datatypes, ABAP
structures or the RFC protocol to communicate with an SAP system.
 Call SAP BC services from SAP systems. You can invoke SAP BC services from an
SAP system. This allows the SAP users to access information that is available via the SAP
Business Connector Server. Thus, SAP Business Connector Server enables business-to-
business integration between trading partners, thereby extending the reach of your SAP
infrastructure to customers, partners, and suppliers.
 Route SAP business documents (IDocs) based on criteria you specify. SAP
Business Connector Server provides rich routing capabilities for IDocs. There is a number of
different transport types available out-of-the-box. These include routing of an IDoc to another
SAP system, to a mailbox or FTP server, or simply to a remote URL in an XML format.
The SAP Business Connector allows you to increase efficiency across the supply chain and
customer loyalty by tightly integrating your business infrastructure with that of any partner. Typical
deployment scenarios for SAP Business Connector can be:
 Real-time integration between supplier inventories and your SAP system
 Real-time integration between product, price and availability information from any number of
suppliers and your purchasing application
 Real-time integration between fulfillment and order tracking applications and your shippers'
internal systems.
Functional Highlights
• Synchronous and Asynchronous Communication with SAP Systems via RFC and
tRFC
• Bidirectional communication to and from SAP systems
• Higher level services to process SAP IDocs and BAPIs
• Easy XML and Internet enabling of existing SAP releases
• Support of BizTalk XML envelopes for BAPI and RFC calls
• Support of unified error handling of BAPIs and RFCs on XML level
• Out-of-the-box support of standard internet protocols HTTP, FTP, Email (client and
server side).

SAP AG
Complete SAP System Integration

The SAP Business Connector incorporates a full-fledged RFC Server and Client. These
provide real-time bi-directional (inbound and outbound) communication to and from the
SAP system. From an SAP application point of view, calling the SAP Business Connector
is no different from calling any other RFC server. The SAP proprietary RFC format is
converted to XML or HTML so that no SAP software is needed on the other end of the
communication line.
The SAP Business Connector supports both synchronous (RFC) as well as asynchronous
(tRFC) calls from SAP systems transparently. Thus, BAPIs and ALE scenarios are
supported.
As a special service, SAP IDocs can be converted to a structured document with direct
access to each single field. This allows you to modify an IDoc’s contents on the fly. For
example, if you want to customize incoming IDocs based on local data format, you can do
so. On the other hand, you may simply access existing BAPIs in SAP systems from a
browser or client application or send XML documents to the SAP system.
Developing applications with the SAP Business Connector requires no knowledge of SAP
data structures, significantly reducing deployment time and cost.
Integrating SAP Systems over the Internet

Most business-to-business scenarios demand that two systems communicate with each
other securely over the Internet, despite existing firewall restrictions. The SAP Business
Connector leverages HTTP/HTTPS to seamlessly exchange data between two or more
SAP systems across the Internet, without requiring changes to the existing security
infrastructure.
In addition, the SAP Business Connector transparently manages communication between
different SAP system versions.
Routing IDocs, RFCs and BAPIs

The SAP Business Connector provides rich routing capabilities for IDocs and
synchronous RFCs, giving you better control of your trading relationships. Within
minutes, you can configure the SAP Business Connector to send an IDoc to another SAP
system or to a remote URL in an XML format.
BAPIs provide a simple way to access SAP solutions. They can be used for both
synchronous and asynchronous calls to an SAP System by using the same XML message
format. Asynchronous BAPI calls are provided by using the ALE services inside the SAP
System. Thus, you can easily leverage ALE mechanisms without having to deal with the
sometimes complex IDoc format. This works for all IDocs which are generated from
BAPIs.
Inside the SAP System, administrators can use the full bandwidth of services provided by
ALE, including:
o Performance benefits through asynchronous processing
o Monitoring services
o Distribution services

SAP AG
BAPI interfaces are developed according to strict development guidelines, which means
they are:
o well-defined
o stable
o implementation-independent
o well-documented
The SAP Interface Repository provides public web-based access to the collection of
BAPI interfaces provided by SAP and to the corresponding documentation.
In short, the use of BAPIs leads to the following advantages:
•SAP solutions are accessed on a standardized, implementation-independent
level. Implementation on the SAP server can therefore be exchanged without
invalidating the (BAPI) interface used by clients.
A business management function which is implemented as a BAPI can be called both
synchronously and asynchronously by using the same XML message.
Support for IDoc- and RFC-XML

The SAP Business Connector is the de-facto XML interface to existing SAP systems
releases. It supports all versions of IDoc- and RFC-XML (XRFC), as specified by the
SAP-XML Specification (see the IFR-XML Format Specification for details). With the
SAP Business Connector Server SAP-XML interface, you can invoke RFCs via XML and
convert IDocs to the SAP-XML format.
Note: the current version of RFC-XML is called XRFC!
Support of BizTalk XML envelopes for BAPI and RFC calls

As a default SAP Business Connector will use the standardized BizTalk XML envelope
format for these XML messages.
This simplifies data exchange with other Web messaging systems.
The BizTalk XML envelope differentiates between an application-specific XML body and
an XML header, which is used to exchange transport-specific information, for example for
routing purposes.
The BizTalk XML envelope can be used with both BAPI and RFC XML calls and also for
both synchronous and asynchronous processing.
Support of Unified Error Handling of BAPIs and RFCs on XML Level

To allow generic error evaluations on the client, regardless of the interface type (BAPI,
RFC) used, the bXML format unifies the error handling of BAPIs and RFCs.
In this way, interface type-specific error handling concepts (BAPI return parameter and
function module exceptions) are converted on an XML level into a standardized type of
error representation.

SAP AG
Built-in BAPI Tools

A set of tools to simplify the handling of BAPI calls has been integrated into the SAP
Business Connector.
For easy identification of the relevant application interfaces, a built-in BAPI Browser has
been added. This browser provides access to the interface data for each business object
and its BAPIs and also serves as a search tool to the SAP interface world. With the built-
in BAPI browser, you can quickly identify the necessary information to set up the routing
rules for BAPIs.
Services to simplify the handling of BAPI transaction control have also been added to the
SAP Business Connector.
Message Store
The SAP Business Connector provides a persistent Message Store that the transaction
manager uses to track all IDocs and all tRFC calls routed to and from SAP systems via
the SAP Business Connector Server.

SAP AG
Architecture and Components
Basic Concepts
To use the SAP Business Connector Server successfully, you should understand the
following terms and concepts:
Term Description
BAPI Business functions in SAP systems, which are written in the programming
(Business Application language ABAP. BAPIs are formalized RFCs. Systems that are remote to
Programming Interface) the SAP server commonly use BAPIs to have the SAP server perform an
action.
RFC Server (Listener) SAP terminology for a process that can accept RFCs from SAP systems.
This allows SAP systems to access functions in external systems. In SAP
BC terminology, this is an RFC Listener.
RFC Listeners are one or more threads on the SAP Business Connector
Server that waits for incoming requests from SAP systems. RFC Listeners
are named and register with an SAP gateway to indicate that they are ready
to accept requests. Listeners can accept RFC or tRFC requests.
RFC Client SAP terminology for a process that sends RFCs to an SAP system to invoke
functions.
tRFC Protocol for ensuring that an RFC is successfully executed and executed
(Transactional RFC) exactly once on the target system. The SAP Business Connector Server can
handle both inbound and outbound tRFCs.
tRFC protocol Communications method that the SAP server uses to asynchronously
invoke a function on a remote system and a remote system uses to
asynchronously invoke a function on the SAP system. The transactional
RFC (tRFC) protocol ensures that an RFC is successfully executed and that
it is executed exactly once.
TID Transaction ID. A 24 bytes long, globally unique identifier used by tRFC to
ensure exactly once execution.
RFC Requests that the SAP server initiates to have functions performed on
(Remote Function Call) remote systems, or calls remote systems initiate to have the SAP server
perform a function.
RFC protocol Communications method that the SAP server uses to synchronously invoke
a function on a remote system, and a remote system uses to synchronously
invoke a function on the SAP system.

SAP AG
Term Description
SAP BC Service SAP Business Connector Server functions (interfaces to data sources, XML
documents, or HTML Web sites) that are named with hierarchical
interface/service syntax. Services can be developed in the languages Flow,
XSLT, Java, or C/C++. They can be developed by you, third-party vendors,
or SAP AG.
IDoc (Intermediate EDI-like SAP business document.

Document)
Partner Manager A process that accepts messages and routes them to a configured location,
for example, messages can be routed to an SAP system, an SAP BC
Server, or a remote URL in an XML format. Typically, IDocs are routed
through the Partner Manager.
Transaction and A file-system-based storage component that the SAP Business Connector
Message Store Server uses to track all transactions that pass through the Partner Manager.
The following illustrates the components in a system that uses the SAP Business
Connector Server:

SAP AG
Architecture and Components
SAP Server SAP BC Server
RFCs and BAPIs SAP BC Services

RFC
RFC Client
tRFC
Requests
RFC mapped to
a service
RFC Server
(Listener)
IDOCs
tRFC Requests
that are not
Partner Manager
mapped to
tRFC a service
Message Store
Invoking Business Logic

The SAP Business Connector Server incorporates an RFC Server and RFC Client to
provide real-time inbound and outbound communication to and from the SAP system.
The Business Connector uses the RFC Client to send requests to execute BAPIs to the
SAP server.
Requesting the Execution of a BAPI from the SAP Business Connector Server
SAP Business Connector Server SAP Server
SAP BC Services
BAPIs
RFC
RFC Client
You can quickly and easily The SAP BC Server

The SAP Server
create a SAP BC service uses the RFC Client
executes the
that invokes a BAPI on the to send the request to
requested BAPI
SAP Server the SAP Server
The SAP Business Connector Server uses the RFC Server (Listener) to listen for
incoming requests to execute SAP BC services from an SAP server. From an SAP
application point of view, calling the SAP Business Connector Server is no different
from calling any other RFC server.
Requesting the Execution of an SAP BC Service from the SAP Server

SAP AG
SAP Server SAP Business Connector Server
RFCs
SAP BC Services
RFC RFC Server
(Listener)
Any function call The SAP BC Server The SAP BC Server

can be directed to listens for RFC executes the SAP BC
the SAP BC’s RFC requests from SAP Service to which the
Server Servers RFC is mapped
Routing Messages through the Partner Manager

When the SAP Business Connector Server receives a request on the RFC Listener that is
not associated with (or mapped to) a specific SAP BC service, the SAP Business
Connector Server sends the request to the Partner Manager. The Partner Manager can
receive:
 IDocs and BAPI calls from an SAP server or IDoc-XML messages from any web client
 RFCs from an SAP server or RFC-XML and bXML messages from any web client
Inbound Requests into the Partner Manager

Requests (on the
local system or via
SAP Business
SAP Server the Internet) are
routed through the
Connector Server
Partner Manager
IDOC
tRFC
RFC Server
RFC (Listener)
RFC, tRFC
Partner Manager
Message Store
An SAP Business Connector inbound call is an outbound call from the SAP system’s point of
view.
When the Partner Manager receives a message with tRFC or an XML-message that
contains a TID, it logs the transaction in the Message Store. It then uses routing rules to
determine where to route the messages. The routing rules indicate where to route the
message based on who the messages is from (sender), who is to receive the message
(receiver), and the message type. A message can be:
 Routed to an SAP server (IDocs, RFCs and BAPIs)
 Routed to an SAP BC service on the local machine or a remote machine
 HTTP posted to an URL

SAP AG
 FTP'd to a location
 Sent via e-mail to a mailbox.
Routing Messages that the Partner Manager Receives

SAP Business
SAP BC Server Connector Server
SAP BC Services
SAP BC Services
Route to a SAP BC service
on a remote system
Route to a SAP BC
service on the local
system
I
SAP Server
P N Route a RFC to a RFC
A Rule SAP Server
R T
T Rule
N E tRFC
Rule
E Route an IDOC to a
R R SAP Server
Rule
M Rule N
A
N Rule E
A
G Rule
T
E HTTP post a URL http://company.com/url
Rule
R
Message Store FTP to a location Machine:4443
Send via an e-mail note To:

From:
Subject:

SAP AG
Chapter 3: Calling an SAP System from SAP BC Services
Overview ............................................................................... 3-2

 General Settings……………………………………………………3-2
Defining SAP Servers ............................................................ 3-4
Creating an SAP BC Service that Executes an RFM ............. 3-16
Creating an SAP BC Service that Executes a BAPI............... 3-23

SAP AG
Overview
You can create SAP BC services that execute a Remote-enabled Function Module (RFM)
residing on an SAP server. A Function Module performs functions against data in the SAP
system. You can create a service for any Function Module that is designated for external
use (i.e. ‘remote enabled’). This includes all BAPIs, which are formalized RFMs. To
create an SAP BC service, you simply select SAP server and the RFC that you want the
service to execute. Such a service is called “RFC Outbound Map”.
After creating the RFC Outbound Map, you can use it at any point in your Business
Connector applications to execute the corresponding RFM in the backend. You can also
allow external HTTP/FTP or SMTP clients to invoke the outbound map.
Before you can create an RFC Outbound Map, you must configure the SAP Business
Connector Server to define the SAP servers you want to use. You identify an alias name
for the SAP server and specify information that the SAP Business Connector Server
requires to connect to the SAP server.
This chapter describes how to map an SAP BC service to a RFM and how to test the SAP
BC service.
You must have Administrator privileges on the SAP Business Connector Server to execute these
procedures. If you do not have such privileges, have your SAP Business Connector Server
administrator perform the following for you.
General Settings
For the general settings of the SAP BC server you can use the Administrator User
Interface:

SAP AG
Setting Description
Timeout (minutes) Delay (minutes) until an unused connection to a SAP

System is timed out (default: 5)
Timeout check period (seconds) Time interval in seconds between checks whether
unused pooled connections have timed out
Sessionpool size Maximal number of connections in one RFC

connection pool to one SAP System (default: 10)
Poolqueue waiting time (seconds) Delay (seconds) until requests waiting for a
connection from a pool time out in the queue
Check time (minutes) Time interval (minutes) between checks of the

listener. It is checked whether the RFC Connection is
still valid. If the backend’s RFC Gateway is running,
any inactive RFC Listener is restarted at the latest
after this interval.
Response time (seconds) Delay (seconds) until a listener responds at the latest
to an incoming request.
Default XRFC version Version of RFC-XML sent. Valid versions: 0.9 and
1.0 (default).

SAP AG
SNC library path Path of the SNC library needed for secure RFC
connections.
CPIC Trace Level The trace level for the CPIC layer. The valid value
range is from 0 (trace is off) to 3 (most verbose
trace).
CPIC Maximum Conversations The maximum number of connections allowed by the

CPIC layer.
Log Throughput data Flag to decide whether to write basic throughput

information to the log.
Use jARM Flag indicating whether or not to activate Java

Application Response time Measurement.
Generate DSR Passport Enable or disable DSR passport generation through

the Business Connector.
DSR Root Directory The DSR root directory (refer to “Monitoring

Information via Passport and DSR“).
Defining SAP Servers

Use the following procedure to define the parameters that the SAP Business Connector
Server will use to establish a connection to an SAP server. The SAP Business Connector
Server requires a connection to the SAP server whenever functionality from the SAP
System is to be invoked, that is whenever SAP Business Connector acts as a client for an
SAP server. But also when SAP Business Connector receives a call from an SAP Server, it
needs to make a callback to the calling system to look up the function interface or IDoc
definition from the SAP DDIC.
To define the connection to the SAP system
1 Start the SAP Business Connector Server.

2 Choose Adapters -> SAP from the SAP Business Connector navigation panel
3 Select the SAP Servers tab.
4 Choose Add SAP Server.
As of version 4.8.1 a new connection type WebSocket is offered in addition to the standard
CPIC communication. Depending on the connection type, different sets of information
must be provided to set up the SAP server.

SAP AG
In the field… Specify…
Connection Type Type of connection, either the traditional connections using the
CPIC protocol or connections using the WebSocket
protocol available with ABAP Platform 1909 (Application
Server ABAP 7.54) or higher.
SAP Server Definition for CPIC Connection
Complete the following fields with the values similar to how you would configure them
in a SAPGui entry.
System
Name An alias for the SAP server. This is the name by which the server
will be known to SAP BC services.

SAP AG
SAP Router String The SAP router string. (Optional)

A router string contains a substring for each SAP Router to set up
a connection in the route: the host name, the port name, and the
password, if one was given.
Example: /H/127.0.0.1/H/
Syntax: /H/ indicates the host name.
The SAP router string is only needed, if there is a firewall between
the SAP server and SAP BC.
For more Information on configuring the SAP router see the SAP
Library on help.sap.com.
Connection Type Select CPIC Connection.
Login Defaults
User The SAP username.
Password The SAP password.
Client The three-digit SAP client number.
Language The logon language. This can be either the one-character SAP
language code. or the two-character ISO language code.
Depending on whether you want to use “direct application server logon” or “group logon/load balancing”,
fill in one of the two following sections:
Server Logon
Application Server The IP address or hostname of the SAP application server.
System Number The SAP system number (0-99).
You can leave all remaining fields at their default values. If you do so, the BC will always connect to the
same application server.
Load Balancing
Complete the following fields only if you apply the group login concept, (in this case you do not need to
enter values in the ‘Server Logon’ section):

SAP AG
Load Balancing If you choose ON, the group login concept is active.
Group Name The name of the group you want to login.
Message Server The hostname or IP address of the message server.
System ID The 3-character system ID of the SAP system.
Advanced settings
ABAP Debug Can be set to "Off" (default) and "On". If set to on, the BC will try
to attach a SAPGui to any newly opened RFC connection, switch
the connection to debug mode and stop execution at the first
ABAP statement of any called function module. See chapter Notes
on the option ABAP Debug.
Use SAPGUI Specifies to use a SAPGui. The default SAPGui will be started
and attached to each new RFC connection being opened. It is
strongly recommended to use this option only if really needed for
executing specific ABAP Remote Function Modules which require
an output to a GUI. The development and usage of such ABAP
RFMs should usually be avoided.
RFC Trace Enables the creation of RFC trace information (Off/On:

without/with trace, Default: Off)
For detailed information on using the RFC trace see pages 5-5
and 5-6
Serialization Format Serialization format to be used for transferring function module

data (Row Based - classic row-based serialization [default] or
Column Based - new column-based serialization)
Network Relevant for the column-based serialization format only. Controls

the type of data compression used depending on the expected
network type to be used by the destination:
• LAN: Fast local area network [default]
• WAN: Slow wide area network

SAP AG
Notes on the option ABAP Debug:

On the backend side, certain prerequisites need to be fulfilled. See SAP note 1258724 for
details.
The SAPGui will pop up on the machine, where the SAP BC process is running, therefore a
frontend type user needs to be logged on at OS level on the machine, where the BC is
running, otherwise the GUI will wait forever without anyone noticing.
If the SAP BC runs as a background process (Windows Service), you need to make sure that
on Windows OS level the settings as described in SAP note 2915426 are defined, otherwise
Windows won't allow the Service to display a graphical UI.
Above all a much better way to debug ABAP function modules is via "external breakpoints",
as this avoids all the aforementioned limitations. To do this, you
• Start a SAPGui on the machine of your choice, this can be any (frontend) machine
and does not necessarily need to be the (server) machine, where the BC is running.
(Note that this way you can debug ABAP function modules even from a SAP BC
that is running on Linux/Unix! All that is needed, is a frontend PC “somewhere”
with an installed SAPGui.)
• Log on to the backend with the same ABAP user as the SAP BC is using, go to
transaction SE37 and display the function module you want to debug.
• Set an ABAP breakpoint of type "external breakpoint" at the line where you want to
stop.
• Start the application on SAP BC that calls this function module.
The execution of the function module from BC side will now be "captured" in your SAPGui
session, you can debug it there, and once debugging is finished, control will switch back to
the SAP BC
Debugging via "ABAP Debug" should be used only in those rare circumstances, where you
cannot use "external breakpoints".
Security Options
SNC enabled Determines whether this server should use SNC or not. Default:
no.
SNC Authentication Authentication method to use:

• SNC Credential
• X.509 Certificate: Requires a certificate
• User and Password
SNC Name Your own SNC name if you don't want to use the default SNC
name. This is the name you chose when generating a PSE.

SAP AG
SNC Partnername SNC name of the SNC partner (RFC server) or SNC name of the
message server (Load Balancing).
SNC Quality of protection, possible values:
Quality of Protection
• Authentication only
• Authentication and integrity protection
• Authentication, integrity protection and encryption
• Use global build-in default settings
• Use maximum value supported by security product
Specifies whether the repository pool for this server should use
Repository uses SNC
SNC protected connections. Default: no.
Choose Save to commit these changes.
Note: If you want to use SNC connections for the communication, there are some more
general and user specific settings required on the SAP application server. These settings
are listed below:
SAP Settings for SNC Table/Parameter
General SAP settings Table SNCSYSACL (SM30, view

for SNC: VSNCSYSACL, TYP=E)
SNC name entry of the SAP
Business Connector
Settings for Certificate

log in:
General Settings: Profile Parameter:

snc/libsapsecu=./libsecude.sl
(if the SAP system runs on HP-
UX)
snc/extid_login_diag=1
snc/extid_login_rfc=1
Table SNCSYSACL (SM30, view

VSNCSYSACL, TYP=E),
activate:

SAP AG
SAP Settings for SNC Table/Parameter
- Certificate log in
- Diag
- RFC
User specific settings: Table USREXTID (view

VUSREXTID),
Category DN
Entry with DN (Distinguished
Name) from user certificate.
The Seq.No. 000 is the default
entry.
Set entry ‘active’
For detailed information on the SAP application server

settings for SNC see the corresponding SAP documentation.
SAP Server Definition for WebSocket Connections
The fields in the sections System and Advanced Settings are the same as with the
CPIC Connection connection type. The following fields are WebSocket specific.
System

SAP AG
Logon Type The authentication type for the WebSocket connection:

• User/Password: Logon with a username and password.
• Default Certificate: Use the client certificate,
signing certificates and private key from the BC Server’s
global certificate settings defined under Security 
Certificates. (see SAP Business Connector Administration
Guide, Configuring the Server to Use SSL).
• Custom Certificate: Specify custom certificates to
authenticate. In this case use the three parameters Client
Certificate, Signing Certificates and Private Key below.
User The username for the WebSocket authentication.
Password The password matching the username.
Client Certificate The path and file name of the BC Server’s certificate to use for
client authentication with the server.
Signing Certificates Comma‐separated list of path and file names signing the client
certificate (certificate chain). List the files containing the
certificates in the following order: intermediate certificate 1, …,
intermediate certificate n, root certificate.
Private Key The private key matching the client certificate to handle signing
and encryption.
Once a SAP Server entry has been created, the password can only be changed via a separate
screen. To display this screen, choose SAP  SAP Servers selecting the Alias of your SAP
Server and then click on the "Change password" link.
When you select Default or Custom Certificates as the Logon Type, the chosen certificate must be
mapped to a user in the target SAP System. In the CERTRULE transaction of the SAP target

SAP AG
system, add the certificate you want to authenticate with. When you selected Custom Certificates,
this is the Client Certificate in the Login Defaults section of the SAP Server definition. If you
selected Default Certificates, it is the Server’s Signed Certificate defined under Security 
Certificates.
Upload the according certificate in the CERTRULE dialog of the target SAP System:
Then select Explicit Mapping to map the uploaded certificate to an existing user in the SAP
System:
In the example above, whenever the BC Server authenticates at the SAP System with the
certificate, the RFC will be executed as the SAP User MYSAPBCUSER. Any function call will
then be authorized based on the access permissions of this user.
Testing the Connection to SAP Servers

Use the following procedure to verify that the SAP Business Connector Server can successfully
connect to an SAP server that you have defined.

SAP AG
To test the connection to an SAP server
1 Choose SAP from the SAP Business Connector navigation panel.

2 Select the SAP Servers tab if it is not already selected.
3 Press on the name of the SAP server for which you want to test the connection.
4 Choose Test Connection.
- If the SAP Business Connector Server can successfully connect to the
specified SAP Server, it will display connection information as shown
below.
- If you receive an error message, choose the SAP Servers tab and verify
that your server configuration information is correct. See previous
procedure. Also check, whether there are any firewalls between your SAP
Business Connector and SAP Server.
- In case of an RFC error message, see the logs\error.log file. This
file contains a more detailed description of the error cause. See also the
SAP Business Connector Administration Guide, ch. Working with Log Files.
In addition, when errors occur testing CPIC connections (Server Logon /
Load Balancing) a detailed logfile dev_jco_rfc.trc will be written to
the server directory.
Connection Information

SAP AG
When testing WebSocket connections, typical error messages are:

• Failed to get SSL Context from destination configuration [hostname]
• Initialization of repository destination [hostname] failed: TLS failure or hostname
verification failed, please check the trace
They typically point to incorrectly configured, outdated or unsigned certificates in the

custom settings of the SAP server or the global certificate settings under Security 
Certificates. Note that the destination server must accept the certificate chain you are
presenting
Testing that the SAP Server will execute an RFM

Once you have verified that you can connect to an SAP Server, you can use the following
procedure to verify that it will accept and process an RFC request from the SAP Business
Connector Server.

SAP AG
To test an RFC from SAP BC
1 Choose SAP from the SAP Business Connector navigation panel to display the
main SAP page if it is not already displayed.
2 Select the Lookup tab.
3 From the drop-down list in the Server Name field, select the name of the SAP
server on which the FM you are to test resides.
4 Enter the name of the FM you want to test in the field Function Name of the
group Function Search. For example, enter BAPI_COMPANY_*. Then select
the Search button. The SAP Business Connector searches for all RFCs that
begin with BAPI_COMPANY_.
5 In the list of matching RFCs that is returned, follow the link of the RFC you want
to test. For this example, choose BAPI_COMPANY_GETLIST. The SAP
Business Connector displays the function signature for the selected FM as
shown below. It lists the imports, exports and tables comprising this FM.
Function Signature
6. Choose Test Function to invoke the FM on the SAP server you selected in step 5.
7. This BAPI doesn’t have any inputs. Just press Test Function again to proceed.
After a few moments, a screen displays the number of companies found.

SAP AG
RFC Test Results
Follow the entries link beside this row count to view the companies found.
Creating an SAP BC Service that Executes an RFM

To create an SAP BC service that executes an RFC, you create an “Outbound Map” for
the FM. This feature allows RFMs to be exposed as standard SAP BC services. After
you create the SAP BC services, business partners, who are interested in calling these
services, can download specifications for the services and generate client code.
Calling a BAPI according to its definition in the BOR is currently not possible with an Outbound
Map. In this case you have to use the BAPI transport.
An SAP Business Connector outbound call is an inbound call from the SAP system’s point of
view.
Terminology
To use SAP Business Connector Server successfully, you should understand the
following terms and concepts:
Term Description
Export Output parameters of a Function Module. Output parameters are simple values
or structures.
Function Signature Specifications of the import, export, and table parameters of an FM. Also known
as a function interface.
Import Input parameter to an FM. Input parameters are simple values (e.g., string or
number) or structures.
Map SAP Business Connector terminology for an association between an FM on an

SAP system and a service on SAP Business Connector Server. These
associations can be created for inbound (SAP calling SAP BC) and outbound
(SAP BC calling SAP) RFCs. Maps can also be used to rename parameters or
filter out selected parameters entirely.
Structure SAP data structure containing one or more fields. This can be thought of as a

SAP AG
Term Description
single row of a table.
Table SAP data structure that is both an import and export to a function. Tables can be
created and passed to an RFC. The FM can modify these tables and return
them. Tables, themselves, are no different from relational database tables,
consisting of a series of fields and rows of data for these fields.
Creating an Outbound Map

Use the following procedure to create an SAP BC service that makes a remote function
call to an FM on the SAP server.
This example shows how to create an outbound map for
BAPI_COMPANY_GETDETAIL, and then test the map using SAP Business Connector.
The authorization profile required for the SAP Logon user when executing an RFC lookup in the
SAP System is described in Authorization Profiles for the SAP Logon User on page 9-10.
To create an Outbound Map for an RFM

3 From the drop-down list in the Server Name field, select the name of the SAP
server on which the FM for which you want to create an outbound map resides.
4 In the Function Search section of the screen, type all or part of the name of the
FM for which you want to create an outbound map. Use pattern-matching
characters if you are unsure of the complete name and want the SAP Business
Connector to search for several RFMs with similar names.
For this example, enter BAPI_COMPANY_* in the Function Name field.
5 Choose Search. The SAP Business Connector Server displays a list of RFMs
that match the criteria you specified in the previous step.
6 Follow the link of the name of the RFM for which you want to create an
outbound map. For this example, BAPI_COMPANY_GETDETAIL.
7 On the next screen, follow the link Define New Map corresponding to an
outbound request (SAP BC calling SAP).

SAP AG
Map SAP BC calling SAP
8. Set the parameters on the Outbound Map for <FM_Name> screen as follows.
(Leave all other fields at their default values.)
In the field… Specify… Description
Folder Demo This is the name of the folder in which the service
you are mapping resides.
Service CompanyGetDetail This is the name of the service to which you are
mapping the FM.
Package Default This is the name of the package into which the
service you are mapping will be generated.
ACL <None> In this field you can select an ACL (Access

Control List), if you want to restrict the use of this
service to users allowed by this ACL.
SAP Business Connector folder and Service names are case sensitive, as are the parameters to the
Flow Service.
Choose Save to add this map to the SAP Business Connector Server.
Searching for maps without reference
For Outbound and Inbound Maps associated with an SAP Server alias, there is an option
to search for maps without reference in the map overview. The symptom, that a map
exists, but is not listed in the function map list, can occur when you distribute a package
containing Inbound/Outbound Maps from a development system to a production system.

SAP AG
In the production BC the maps exist, but are not referenced in the function map list of the
associated server.
To add maps without reference
1 Select ‘SAP -> SAP servers’ in the Administrator UI.
2 Click on the ‘Maps’ icon of the server to be configured:
3 Click on the "Find Maps for <serverName>" link at the top of the 'RFC function maps’
screen. This will display a list with all maps found.
4 Select the maps you want to add and press the ‘Add’ button. The corresponding maps will
be added to the function map list and will be referenced from now on.
Note: There can only be a single reference for an Outbound Map in the map list. If
there are multiple entries for Outbound Maps of the same function module, only the
first one will be referenced. Although all of them will work, it is still preferable to
have a single Outbound Map that is called from all locations.
Using optional tables in Outbound Maps
Since release 3.5.2 optional tables are really optional, i.e. if an optional table is not passed
to an Outbound Map, there won't be any values returned for that table. If the table is
optional and should not be filled in the request, then how can the Outbound Map return
data for that table in the response? The answer is simple:

SAP AG
Example: you are calling an Outbound Map named opotional_table_demo. In this Outbound
Map there is an optional table called T_OPT_SBCOPT. To pass this table use the "Set value”
button for this parameter.

SAP AG
The only thing you have to do now is to uncheck "Overwrite Pipeline Value", then the
empty table is only the default value. With these settings the optional table will always be
returned in the output, both, when a filled table is passed in as input for the function call,
as well as when there is none.
Testing the Function Module
Use the following procedure to test the service you just created.
To test an Outbound Map for a Function Module
1 Choose Packages -> Management -> Browse Folders from the SAP
Business Connector navigation panel.
A list of available top-level folders appears.

2 Follow the link Demo to view the Services within the folder.
You will see your service CompanyGetDetail. This is the SAP BC Service
mapped to BAPI_COMPANY_GETDETAIL.
3 Choose the checkmark Test that corresponds to the CompanyGetDetail

service.
The Test 'Demo:CompanyGetDetail' screen appears. This screen contains
fields you use to specify input into the service.
4 Enter 001000 into field COMPANYID to specify input.
5 Choose Test with inputs.
The results of BAPI_COMPANY_GETDETAIL will be displayed in table

form in the browser.

SAP AG
After you create an SAP BC Service that executes a function module, you can create
other SAP BC Services and clients that invoke the Service.
Testing that the SAP Server will Execute an RFC-XML

You can invoke a function module with RFC-XML from the SAP Business Connector
Server via the Lookup screen of the SAP BC Administrator user interface. This screen
contains an RFC-XML template you can use to invoke function modules.
Perform the following procedure to access the Lookup screen and invoke a function
module via RFC-XML.
To invoke a function module via XML from the SAP BC Server

3 Enter the function module you would like to invoke via XML in the field Function
Name in section Function By Name.
4 Choose RFC-XML.
This generates a form containing the XML template necessary to invoke the function module. Fill in the
appropriate inputs and choose Invoke on <SAP server>. You will see the XML response in the browser (you
may have to select View Source to see the actual XML source in your browser).
Posting an RFC-XML Document from an HTTP Client

There are several possible ways to invoke an Outbound Map that will call a function
module. It is important that you understand the namespace convention for services (see
Administration Guide 4.8). To invoke the service illustrated previously you need to call
the URL http://<sapbc>:<port>/invoke/<folder1>.<folder2>/<service>
1. In an interactive scenario you can simply call it from a browser the
same way you call any other service on SAP BC. The input
parameters must then be URL encoded, e.g.
http://localhost:5555/invoke/demo/CompanyGetDetail?
COMPANYID=001000
The response can then be rendered via an HTML template ( for more
information please refer to the Templates and DSPs Guide).
2. In a fully automated scenario your application would, however, send the
request XML document to this service. A template for a valid request
document for each FM can be generated from the Lookup menu by clicking
the 'RFC-XML' button. To invoke the Outbound Map with it you have to
post it in the HTTP body of the request to the URL (as above). Your
application also has to set some keys in the HTTP Header:
POST /invoke/<your complete service name> HTTP/1.1

--> the service name to be called
Host: <xyz>
--> host of http client
Content-type: application/x-sap.rfc

SAP AG
--> you have to set the content type. When sending an RFC-XML
document, the content type has to be application/x-sap.rfc
Cookie: ssnid=<4711>
--> This is optional. On the first connect SAP BC will generate
a session cookie. When you use this for the following
communication you will be assigned to the same SAP BC
session. If you do not use the session cookie a new SAP BC
session will be created with every HTTP request.
Content-Length: <the length of the HTTP Body>
The HTTP Body then has to consist of the XML document, encoded in RFC-XML.
Depending on whether the call was processed successfully or not, you will get a response
or an exception XML document (see the document packages/SAP/doc/RFC-
XML.html). You can also force SAP BC to invoke the Function Module with tRFC by
setting a transaction ID in the Envelope of the XML document. However, you should
bear in mind that only FMs without return parameters can be called with tRFC.
To simulate a raw post, you can use the service pub.client:http.

1 Using the SAP Business Connector Developer, open the
WmPublic package and navigate to the service pub.client:http.
2 Choose Test  Run.
3 Specify the URL of the RFC-XML handler service. For example,
http://localhost:5555/invoke/pub.sap.transp
ort.RFC/InboundProcess (if the document contains
routing information).
4 Specify Post as the method.
5 Add one entry in the field headers

Name: Content-type
Value: application/x-sap.rfc
Creating an SAP BC Service that Executes a BAPI

The lookup-tool has been enhanced by adding a built-in BAPI Browser. You can use this
tool for an overview of the BAPI interfaces inside your SAP System, and also to directly
call a BAPI via XML.
Starting to Browse
You can start browsing your BAPIs using the Lookup tab. Here you can enter the name of
a business object and a BAPI. This selection always applies to the SAP System selected
in the field Server Name.

SAP AG
There are several ways you can fill out the form:
In the group BAPI By Name enter the full name of the business object and BAPI. You can
either view the details of the BAPI by selecting Lookup or directly invoke the BAPI via
XML by pressing on bXML.
In the group BAPI By Name enter only the name of the business object. Choose Lookup to
view details of the business object and select one BAPI from the list of available BAPIs
for the business object.
In the group BAPI By Name enter * in the business object field to view a list of all
business objects available in the selected system.
Note: Please keep in mind that business object and BAPI names are case-sensitive.
Displaying a List of Business Objects in the System

By entering * in the business object field on the Lookup main page, you can view a list
of all business objects available in the selected system.

SAP AG
Each link in this list represents a business object. If you follow the link, you will get a
detailed view of this business object. Please note that this list may also contain business
objects that do not contain BAPI methods.
Displaying a Business Object

By entering a correct name of a business object in the corresponding field on the Lookup
main page, you can view detail information for this business object. The detailed
information consists of a list of all the key fields of a business object and a list of all its
BAPI methods. For business objects, which only provide instance-independent methods
(“static” methods in programming languages like C or JAVA), the Key fields list is
empty.
For business objects that do not provide BAPIs, the list of BAPIs will be empty.
Just follow the links to the corresponding table fields to display more information on a
specific key field or BAPI.

SAP AG
Displaying a BAPI
By entering the full name of the business object and BAPI in the corresponding field on
the Lookup main page, you can display detailed information of the BAPI. You can also
display this information by following the corresponding link on the display page for a
business object.
Field Description
Static method The Static method flag is true, if the BAPI is an instance-independent method. In
practice, that means that you do not have to specify the business object’s key
fields when calling this method.
Factory method The Factory method flag is true, if the BAPI is used to create an object instance
inside the SAP System. Factory methods return the key fields of the business
object.
Function Module The Function Module (formerly known as Implementing RFC) is the message
type that has to be used to set up routing for synchronous calls coming from a
SAP System. This is technically realized via RFC, so here the name of the
corresponding RFC function module inside the SAP System is provided.
Although it is possible at the moment, it is not recommended to call BAPIs
directly via RFC-XML, as this would only be an implementation-dependent view
of the BAPI.
Parameters The Parameters field contains a list of all parameters in the BAPI interface. By
selecting this link, you can display more information on each parameter. Please
note that the key fields of a business object are not displayed in this parameter
area but in the key fields area on the business object detail page.
By using the Create XML template button, you can generate the XML message that has to be used
to invoke this BAPI via XML. After it has been generated, you can immediately send the XML to
the SAP Business Connector for testing purposes (see below).

SAP AG
Displaying a BAPI Parameter

By selecting a specific parameter from the list of parameters provided on the BAPI detail
page, you can display additional information for this parameter.
Field Description
Internal Name The internal name of the parameter is displayed.
Direction The use-direction of the parameter is displayed. BAPIs use importing, exporting
and changing (= importing and exporting) parameters.
Optional If the flag Optional is set to true, you can omit this parameter in an XML
message. Usually, the implementation inside the SAP System uses specific
default values for optional parameters that were omitted.
Table If the flag Table is set to true, this parameter may consist of several lines. Each
line has the data type specified in the ABAP Dictionary Type field.
ABAP Dictionary Type The ABAP Dictionary Type is a link to the data type description used for this
parameter. This may be a whole structure or just a field of a structure. By
following the hyperlink, you will always see the whole structure.
Displaying a Key Field

By selecting a specific key field from the list of key fields provided on the business object
detail page, you can display additional information for this key field.
Field Description

SAP AG
Internal Name The internal name of the key field is displayed.

ABAP Dictionary Type The ABAP Dictionary Type is a link to the data type description used for this
parameter. This is usually a field of a structure inside the SAP Data Dictionary.
By following the hyperlink, you will see the whole structure.
Please note that key fields are used with instance-dependent (non-static) methods and with factory
methods.
In calls to these methods, the key fields of the corresponding business object have to be
specified as attributes of the business document root element
Using the key field CompanyCodeId in a call to the CompanyCode.GetDetail:
<?xml version="1.0" encoding="iso-8859-1"?>
<biztalk_1 xmlns="urn:biztalk-org:biztalk:biztalk_1">
<header>
…
</header>
<body>
<doc:CompanyCode.GetDetail CompanyCodeId="0001"
xmlns:doc="urn:sap-com:document:sap:business"
xmlns="" >
</doc:CompanyCode.GetDetail>
</body>
</biztalk_1>
Generating XML Calls for a BAPI

By entering the full name of the business object and BAPI in the corresponding field on
the Lookup main page and then choosing Create XML Template, you can generate an
XML message representing the call to this BAPI. You can also generate this message by
following the corresponding link on the display page for a BAPI.
The page displays the XML message needed to call the BAPI which is wrapped in the
BizTalk XML envelope.
You can edit the XML and enter your specific data into the pre-generated XML elements
for parameters and key fields.
You can also adjust the pre-generated information in the BizTalk XML header fields that
are filled with default data.

SAP AG
There are three ways of calling the BAPI, which can be selected through the dropdown
list:
Synchronously calling the BAPI in an SAP System.
Asynchronously calling the BAPI in an SAP System. This only works for BAPIs that are
mapped to an ALE interface. To see whether the BAPI is mapped to an ALE
interface, check the BAPI detail page. If an ALE message type is specified, the BAPI
is asynchronously callable.
Applying routing rules: The call will be sent to the BAPI inbound process of the Partner
Manager that will check, if a routing rule for this BAPI call exists, and will forward
the call to the specified service. This will only work, if a correct routing rule has been
setup, otherwise you will receive an XML error-message.
When you select one of the first two options, the SAP Business Connector will execute a
synchronous or asynchronous call without checking the existence of a transaction
identified in the XML message. However, when using routing or when posting directly to
BC services, you have to specify a transaction identifier in the XML message, if you want

SAP AG
to execute an asynchronous call. If you want to execute a synchronous call, you do not
need to specify a transaction identifier.
After choosing the invoke button, the result of your XML call is displayed. In case of
synchronous processing, this will be a BizTalk message with either the exporting
parameters of the BAPI or with an error message.
For asynchronous calls, this will be a BizTalk message with an empty body in the case of
success or with an error message, if the message could not be delivered to an SAP System.
Application specific errors are not returned in the case of asynchronous calls, but you can
use the ALE monitoring tools in the target SAP System to check these errors.
Posting a BAPI from an HTTP client

For reference on how to call a BAPI from an external client using an XML document,
please refer to chapter Posting BAPI-based XML to the SAP Business Connector, on
page 6-3.

SAP AG
Chapter 4: Calling SAP BC Services from an SAP System
Overview ..................................................................................... 4-2

Creating an RFC Destination on an SAP System .......................... 4-2
Configuring an RFC Listener in SAP Business Connector Server .. 4-7
Mapping Inbound RFCs to SAP BC Services ...............................4-20
Sending an RFC from an SAP System to SAP BC .......................4-24
Working with different code pages ...............................................4-30

SAP AG
Overview
You can create ABAP reports on the SAP server that invoke SAP BC services. This
allows SAP users to access the information that is available to the SAP Business
Connector.
Before you can create a report that invokes an SAP BC service, you must configure the
SAP server to have an RFC destination for an SAP Business Connector Server. This
defines to where the SAP server should send RFC calls that invoke an SAP BC service.
You must also configure the SAP Business Connector Server to have a listener (RFC
Server) that listens for RFCs from the SAP server.
After you have the SAP server and the SAP Business Connector Server configured, you
can create a function module on the SAP server that will be mapped to an SAP BC
Service. You also need to create an “RFC Inbound Map” on the SAP Business Connector
Server. The Inbound Map indicates what service the SAP Business Connector Server is to
execute when it receives the RFC from the SAP Server.
Creating an RFC Destination on an SAP System

To enable your SAP Server to issue remote function calls (RFCs) for SAP BC Services on
an SAP Business Connector Server, you must define an RFC destination on the SAP
Server. Each SAP Server has a single RFC destination for an SAP Business Connector
Server that identifies where the SAP Server sends all RFCs that invoke an SAP BC
Service.
Register SAP Business Connector as an RFC Destination

Use the following procedure to configure the SAP Business Connector Server as a
registered RFC destination on the SAP Server.
You must have the proper authorizations on your SAP system to add an RFC Destination. If you
do not have this authorization, have your SAP administrator perform the following steps.
To register SAP BC as an TCP/IP RFC destination
1 Use the SAP GUI to login to the SAP system.

2 Choose Administration → System Administration → Administration
→ Network → RFC Destinations (transaction SM59).
3 Choose TCP/IP connections.

SAP AG
4 Choose Create.
5 In Destination field, type a name that will meaningfully identify both
the SAP Business Connector Server and the SAP system itself. For
example, if the SAP system is named CER and the SAP BC Server
is named SBC, name your RFC destination SBCCER. You will
need to re-enter this name several times during the course of this
section, so keep it simple and memorable.
This field is case sensitive. We recommend that you pick a name that is all
UPPERCASE characters.
6 In the Connection Type dropdown select the entry T RFC

Connection to external program using
TCP/IP and select the green OK checkmark.
7 You are now presented with the connection details dialog:
Enter SAP Business Connector in the Description 1

field.
8 In the Technical Settings tab choose Registered Server Program as
Activation Type.
9 In field Program ID type the name of your RFC destination from
step 5. Enter it exactly as you did in step 5. This is also a case
sensitive field.

SAP AG
10 Further down in the same tab locate the Gateway Options.

11 Enter the <sap system application server> in field
Gateway Host.
12 Enter sapgw<sap system number> in field Gateway
Service.
This guarantees that you can access the RFC Server from all SAP application servers of the SAP
System.
13 Choose Save at the bottom of the dialog or in the menu More 
Connection  Save.
Remain on the current screen while you complete the steps for creating an SAP Business Connector
RFC Listener.
To connect SAP BC via a WebSocket RFC destination
1 Use the SAP GUI to login to the SAP system.

2 Choose Administration → System Administration → Administration
→ Network → RFC Destinations (transaction SM59).

SAP AG
3 Choose WebSocket RFC.

4 Choose Create.
5 In Destination field, type a name that will meaningfully identify both
the SAP Business Connector Server and the SAP system itself. For
example, if the SAP system is named BCO and the SAP BC Server
is named BCCH, name your RFC destination BCCHBCO.
This field is case sensitive. We recommend that you pick a name that is all
UPPERCASE characters.
6 In the Connection Type dropdown select the entry W RFC

connection to other ABAP system using
WebSockets and select the green OK checkmark.
7 You are now presented with the connection details dialog:
Enter a meaningful description into the Description field.

SAP AG
8 Enter the host the BC server is running on into the host field. This
can be a human readable host name or an IP4 address like
10.20.0.33.
9 Enter the network port on which the BC server’s WebSocket
listener will be listening on. You specify the port when configuring a
WebSocket listener in BC. See To create a WebSocket RFC
Listener on the SAP Business Connector Server.
Note that ports may be occupied by other programs or services on the target
BC host. Make sure the port you pick is still available and can be reached
from outside the host.
10 If you want or need to use a proxy to reach the BC host enter the
according proxy hostname or IP into the Proxy Host field and the
proxy port into the Proxy Service field. If it is an authenticated
proxy, provide the proxy credentials in Proxy User and Proxy
Password.
Note that by using this feature, you can easily connect to SAP BC
servers running outside the LAN segment of the SAP system!
11 A WebSocket connection needs to authenticate at the server.
Navigate to the Logon & Security tab where you can either
authenticate by user/password or by certificate(s).
WebSocket authentication by User/Password

SAP AG
WebSocket authentication by Certificate
To authenticate by user/password, check the by User/Password

option and enter the name and password of a valid BC user under
which the RFC shall run on the BC server.
To authenticate by certificate, check the by X.509 Certificate option

and in Security Options select a X.509 certificate the BC server will
accept as a client certificate. To make the BC server accept the
selected certificate make sure the certificate itself or one in its
certificate chain is trusted by the BC server. To set trusted
certificates in the BC Server see SAP Business Connector
Administration Guide, chapter Configuring the Server to Use SSL.
See also Authentication when SAP BC acts as RFC-Server for

more information.
Configuring an RFC Listener in SAP Business Connector Server

The SAP Business Connector Server requires an RFC listener (RFC Server) to listen
for inbound RFC requests from an SAP Server.
Use the following procedure to create a listener on the SAP Business Connector
Server to respond to RFCs issued by the SAP Server.
To create a TCP/IP RFC Listener on the SAP Business Connector Server

2 Select the SAP Servers tab, if it is not already selected.

SAP AG
3 In the Listeners column list of installed SAP servers, select the number
(initially 0, indicating that there are no listeners defined) corresponding
to your SAP Server for which you want to create a listener.
4 Choose Add Listener.
9. Complete the following fields of the SAP Listener Definition page.

Connection Type TCP/IP or WebSocket. The set of fields to fill in changes depending on
your selection. Chose TCP/IP.
Program ID The Program ID that you specified when creating the corresponding
RFC destination on the SAP server. This field is case sensitive.
Number of Threads The number of simultaneous incoming RFCs that this Listener can
handle.
Gateway Host Gateway Host for accessing your SAP server.

This must be exactly the same parameter as you chose for the
corresponding RFC destination in the SAP system.
Gateway Service The Gateway Service. This corresponds to your SAP system number. If
your SAP system number is "01" then your gateway service is
"sapgw01."
Again, this must be exactly the same parameter as you chose for the
corresponding RFC destination in the SAP system.
Autostart Whether this listener will start automatically when the SAP Business
Connector Server starts.
Select Yes to have SAP Business Connector automatically start the
listener when the Server is started.
If you select No, you will have to manually start the listener after the
SAP Business Connector Server is started. To manually start the
listener, from the SAP Servers tab page, choose the number in column
Listeners for the appropriate SAP server. Then, press the red icon in

SAP AG

field Started?. The icon becomes green when the listener is started.
Once a listener is enabled, a connection exists between the SAP Server and the SAP Business
Connector.
RFC Trace Whether you want RFC tracing enabled or disabled.

For a productive system, select Off. When you select ON, SAP
Business Connector Server collects tracing in .trc files in directory
<installation path>\Server\. The names of the .trc files all begin with rfc.
(For detailed information see ‘Managing RFC Trace Information’ and
‘Viewing and deleting RFC Trace Files’, pages 5-5, 5-6).
Repository Server The SAP server alias is used as a repository for function interfaces and
structure definitions of inbound calls. This way it is possible to use
RFMs even if they are not defined in the calling system.
Use IDoc Segment Flag indicating whether partner profiles should be queried if possible in
Release from Partner order to create documents with the therein defined release.
Profile
If the listener receives requests for function modules, whose metadata is not yet in the DDIC
cache, it must be able to log in to the Repository System. Otherwise, it will fail to start up or will
return errors when receiving incoming RFCs. The above fields must be completed thoroughly and
accurately. If this information is incorrect or left blank, the listener will fail to start.
10. Choose Save to commit these settings to the SAP Business Connector Server.
11. To start the listener, press the read ball in the Started? column.
After a short pause, the ball turns green.
If an error occurs during startup, the state ball will turn yellow when refreshing the page. Click
the yellow ball to receive the error message. Error messages at this stage typically indicate a
problem with either the listener configuration or the network. Review the listener settings and
check the network.
Managing RFC Trace Information

In the development and test phase it is sometimes helpful to view RFC traces, if there are
problems with the function modules, you are trying to call. In order to avoid the need to
access the file system of the machine, on which the Business Connector Server is
running, it is possible to view and delete RFC Trace Files and SAP Log Files from the
Administrator UI.
Testing the RFC Listener

Use the following procedure to verify that the SAP server can successfully issue a remote
function call (RFC) to the SAP Business Connector Server.

SAP AG
To Test the RFC Listener
1. Toggle back to your SAP GUI session. If your screen does not contain a Test
Connection toolbar button, take the following steps.
1.1 Choose Administration → System Administration → Administration → Network → RFC
Destinations (transaction SM59).
1.2 Open the TCP/IP connections folder.
1.3 Select the RFC destination you previously created.
2. Select the Test Connection toolbar button.
- If the SAP server can successfully connect to the SAP BC RFC Listener, it will display connection
information as shown below.
- If you receive an error message, review the steps for creating an RFC Destination and creating an
RFC Listener to verify your configuration settings.
Connection Statistics
To create a WebSocket RFC Listener on the SAP Business Connector Server

2 Select the SAP Servers tab, if it is not already selected.
3 In the Listeners column list of installed SAP servers, select the number
(initially 0, indicating that there are no listeners defined) corresponding to
your SAP Server for which you want to create a listener.
4 Choose Add Listener.
5 Complete the following fields of the SAP Listener Definition page. (Leave
all other fields at their default values.)

SAP AG
Connection Type TCP/IP or WebSocket. The set of fields to fill in changes depending on
your selection. Chose WebSocket.
WebSocket Port The network port on which the BC listens to incoming WebSocket
connections. This must be the same port you specified in the SAP
system when you created the WebSocket RFC destination in the Port
field in the Technical Settings tab.
Note that ports may be occupied by other programs
or services on the machine BC is running on.
Make sure the port you pick is available and can be
reached from the SAP system you want to connect
from.
Number of Threads The number of simultaneous incoming RFCs that this Listener can
handle.
Autostart Whether this listener will start automatically when the SAP Business
Connector Server starts.
Select Yes to have SAP Business Connector automatically start the
listener when the Server is started.
If you select No, you will have to manually start the listener after the
SAP Business Connector Server is started. To manually start the
listener, from the SAP Servers tab page, choose the number in column
Listeners for the appropriate SAP server. Then, press the red icon in
field Started?. The icon becomes green when the listener is started.
Once a listener is enabled, a connection exists between the SAP Server and the SAP Business
Connector.
RFC Trace Whether you want RFC tracing enabled or disabled.

For a productive system, select Off. When you select ON, SAP
Business Connector Server collects tracing in .trc files in directory
<installation path>\Server\. The names of the .trc files all begin with rfc.
(For detailed information see ‘Managing RFC Trace Information’ and
‘Viewing and deleting RFC Trace Files’, pages 5-5, 5-6).
Repository Server The SAP server alias is used as a repository for function interfaces and
structure definitions of inbound calls. This way it is possible to use
RFMs even if they are not defined in the calling system.
Use IDoc Segment Flag indicating whether partner profiles should be queried if possible in
Release from Partner order to create documents with the release defined therein.
Profile
If an RFC Listener receives requests for function modules, whose metadata is not yet in the
DDIC cache, it must be able to log in to the Repository System. Otherwise, it will fail to start up
or return errors when receiving incoming RFCs. The following fields must be completed
thoroughly and accurately. If this information is incorrect or left blank, the listener will fail to
start.

SAP AG
6 Choose Save to commit these settings to the SAP Business Connector

Server.
7 To start the listener, press the red ball in the Started? column. After a
short pause, the ball turns green.
If an error occurs during startup, the state ball will turn yellow when refreshing the page. Click
the yellow ball to receive the error message. Error messages at this stage typically indicate a
problem with either the listener configuration or the network. Review the listener settings and
check the network.
Configuring certificate authentication for WebSocket Listeners

With WebSocket connections, the SAP System and the BC Server trust each other based on
certificates. To make the SAP System trust a BC Server WebSocket Listener, the BC Server
presents the Server's Signed Certificate configured under Security  Certificates to the SAP
System. The SAP System must trust the certificate itself or one of its signing certificates
configured under Signing Certificates (comma-separated).
Inversely a BC Server’s WebSocket Listener must trust at least one certificate presented by the
SAP System. If the BC Server does not trust the SAP System’s WebSocket request, follow the
steps outlined in Testing the WebSocket RFC Listener to add a certificate to the SAP System’s
WebSocket client.
The WebSocket Listener reads the certificates defined under Security  Certificates when it
starts. Stop and restart all WebSocket listeners when you have changed any of these certificates.
At restart the WebSocket Listener re-reads the configured certificates.
Managing RFC Trace Information

In the development and test phase it is sometimes helpful to view RFC traces, if there are
problems with the function modules, you are trying to call. In order to avoid the need to
access the file system of the machine, on which the Business Connector Server is
running, it is possible to view and delete RFC Trace Files and SAP Log Files from the
Administrator UI.
Testing the WebSocket RFC Listener

Use the following procedure to verify that the SAP server can successfully issue a remote
function call (RFC) via WebSockets to the SAP Business Connector Server.
To Test the WebSocket RFC Listener
1 Toggle back to your SAP GUI session. If your screen does not contain a Test
Connection toolbar button, take the following steps.
1.1 Choose Administration → System Administration → Administration → Network → RFC
Destinations (transaction SM59).
1.2 Open the WebSocket RFC folder.
1.3 Select the RFC destination you previously created.
2 Select the Test Connection toolbar button.

SAP AG
- If the SAP server can successfully connect to the SAP BC WebSocket RFC Listener, it will display
connection information as shown below.
- If you receive an error message, review the steps for creating an RFC Destination and creating an
RFC Listener to verify your configuration settings.
Connection Statistics
If an error occurs when testing the connection, the BC Server might not trust the certificate the
SAP Server is presenting when negotiating the connection. On one hand the SAP System must
trust the certificate specified under Security  Certificates  Server’s Signed Certificate and its
certificate chain. On the other hand, the BC System will obviously trust its own Server’s Signed
Certificate when the SAP System presents it. One possibility to make the BC Server trust the
SAP System is to add the BC Server’s Signed Certificate to the SAP System’s SSL client
certificates in the transaction STRUST.
Make sure the certificate is included in the certificate list you selected when configuring the
WebSocket RFC destination.
Another way is to add the signing root certificate of the SAP system’s SSL client certificate to the
SAP BC’s trusted directory.

SAP AG
Monitoring information for RFC Listeners
Viewing and deleting RFC Trace Files and SAP Log Files
In the Administrator UI browse to "SAP  Monitoring". Here you can view and delete
RFC Trace Files and SAP Log Files.
RFC Trace Files are split into several parts, each of them containing one trace entry along
with the date and time it was created. Large SAP Log Files are split into several parts of
about 500K. In this way it is avoided that the browser has to load too large documents,
which would take a long time or even cause a time out. Using the "Back" button of your
browser, you can return from the display of one part to the list of parts for that file.
If you try to delete a file that is still open (e.g. because the Server is still writing to it), you
will get a notification, and the file is not deleted.
Performance output information in the SAP Log File
If the feature Log Throughput data has been set to “On” on the SAP  Settings page and
if the log level for Component=SAP is 7 or higher, you can view performance output
information for the BC server in the SAP log file. The corresponding terms are described
below:

SAP AG
The term… Specifies…

The number of calls that were traced with this Performance
1 No. of calls
Object. For client performance data this is normally 1, if a
session is locked or for listener performance data it can be
more than one.
2 No. of bytes sent Total number of (uncompressed) bytes of data sent from the Business
Connector to the SAP system. In the RFC layer that might be less
because of compression.
3 No. of bytes received Total number of (uncompressed) bytes of data received by the
Business Connector from the SAP system. In the RFC layer that might
be less because of compression.
4 Time for marshalling Time needed for transferring the data from JCo Java Objects to RFC C
(ms) structures.
5 Time for Time needed for transferring the data from RFC C structures to JCo
unmarshalling (ms) Java Objects.
6 Time for middleware Time needed for executing a function module in an SAP system.
calls (ms)
7 Time for handling Time needed to handle an inbound request from an SAP system in the
request (ms) Business Connector after unmarshalling and before marshalling the
data.
8 Total elapsed time Total time needed for handling inbound/outbound calls in JCo layer.
(ms) (1)-(8) is the performance data of the JCo layer. In addition to that
there is data available for the Business Connector data layer seen in
(9)-(14).
9 BC Data: Time for Time needed for transferring the data from Business Connector
marshalling (ms) Objects (pipeline representation) to JCo Objects.
10 Time for Time needed for transferring the data from JCo Objects to Business
unmarshalling (ms) Connector Objects (pipeline representation).
11 Time for preparing Time needed for preparing execution of a function module (outbound
(ms) calls) or invocation of a service. This includes repository queries for the
data structures and the function interface, opening connections to the
involved systems, etc.
12 Time for RFC calls Time needed in the JCo layer for outbound calls. Should be equal to 8)
(ms)
13 Time for BC service Time needed for the invocation of a service to handle an inbound
calls (ms) request in the Business Connector after preparing/marshalling and
before unmarshalling the data. (Listener performance data).

SAP AG
14 Total time for function Total time needed for handling inbound/outbound calls in BC layer.
calls (ms)
jARM (Java Application Responsetime Measurement)
The purpose of this type of monitoring is to give an overview of the status of a Java
system. You’ll find this information on the SAP  Monitoring screen:
Monitoring screen
At the bottom of this screen you will find the following jARM information:

SAP AG
jARM information
jARM Overview Summary of all jARM Requests.
Requests total Number of requests executed so far.
Request rate Requests per second since the jARM Monitoring has been started.
Requests ok Number of successful requests.
Requests with Number of requests with errors.

errors
Components total Number of components used in requests.
Components per Average number of components per request.

request
Total time Execution time for all requests in milliseconds.
Average time Average execution time for a request in milliseconds.
jARM Requests You can get the TOP 100 requests, i.e. the requests that needed the
longest execution times. To restrict those entries, you can specify two
inputs before pushing the "Show"-Button:
Info for … Enter a wildcard-like pattern for the request names, for which you want
the information. You can use only exact patterns and patterns with a
single '*' at the end, such as 'IDoc*'. You cannot make entries with the
format '*XML*'.
max. listed Limits the number of requests to the given number. After pushing the
Requests button, the jARM Requests Overview is displayed.
jARM Components You can get accumulated information about all components, which
have been used in Requests. To restrict those entries, you can specify
an input before pushing the "Show"-Button:
Info for … Enter a wildcard-like pattern for the Component names, for which you
want the information. You can use only exact patterns and patterns
with a single '*' at the end, such as 'client.*' You cannot make entries
with the format '*Render*'. After pushing the button, the jARM
Components Overview is displayed.
jARM Users You can get accumulated information about all users that have been
used in requests. To restrict those entries, you can specify an input
before pushing the "Show"-Button:

SAP AG
Info for … Enter a wildcard-like pattern for the usernames for which you want the
information. You can use only exact patterns and patterns with a single
'*' at the end, such as 'DOE*' You cannot make entries with the format
'*SMITH*'. After pushing the button, the jARM Users Overview is
displayed.
Monitoring Information via Passport and DSR

Distributed Statistical Records (DSR) is a tool to collect performance data for transactions
which are being processed by several "components" spread over different physical hosts.
For example a trading partner might send an XML document to the Business Connector,
the Business Connector converts it to RFC data and passes it on to an SAP application
server, which in turn processes the data and finally saves the results in a database.
So here three "components" (on three different machines) are involved in processing the
data: the Business Connector, the SAP application server and the database server. In
scenarios like these it may be quite difficult to trace the performance and find bottlenecks.
To tackle this task, DSR and passport have been designed. For more information please
consult the latest documentation of SAP CCMS.
Starting with Release 4.7 the Business Connector can be setup to accept passports from
other components and pass them on to other components and to write its own performance
records.
Prerequisites
On Business Connector side everything is prepared for the support of passports and DSR.
Setup
You can enable DSR support on the Business Connector as follows:
1 Install the necessary version of sapccmsr on the machine and find out the
directory that sapccmsr uses for storing statistical records. (On Windows
this can be found in the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\SAP\CCMS\DSR\DirDsr. For Unix
please see the documentation of sapccmsr.)
2 Go to Adapters  SAP  Settings, go into change mode and set the
following two parameters:
DSR Root Directory=<directory from step 1.>
Generate DSR Passport=on
3 Restart the Business Connector
Reported Values
When the Business Connector receives a message via the RFC Listener, Reverse Invoke,
HTTP(S) Listener, Email Listener or FTP Listener, it accepts the passport from the sending

SAP AG
SAP system (in the case of RFC Listener) or creates a new passport (in the other cases).
Also, if a Service is started in the Scheduler, a new passport for the invocation is created.
Then the Business Connector collects the following information regarding the processing
of this message:
Startdate yyyyMMdd
Starttime HHmmss (in GMT+00)
Enddate yyyyMMdd
Endtime HHmmss (in GMT+00)
GUID The 32-digit GUID from the passport. This serves to
identify the transaction across system boundaries.
Action The name of the Flow/Java Service being invoked.
Action type One of the following:
1. SAP BC is called via RFC
2. SAP BC is called with an XML document via
http(s), ftp or email
3. SAP BC is called via IDoc
4. A transaction is started via Service Invocation
or in the Scheduler
UserId Business Connector User under which the Service is
executing.
LOAD The time in ms, the Business Connector needs to
convert the RFC data to IData (Records and
RecordLists). This field is used only, when the BC is
called via RFC Listener.
WAIT The time in ms, the Business Connector is waiting for
other components (databases, FTP&Web servers, SAP
systems etc.)
RESP Total processing time in ms including the wait time.
MEM Size of received document in bytes. This field is used
only, when the Business Connector is called via
HTTP(S), FTP or Email Listener.
Additional information Information as to how this message was
received/started. One of the following: Scheduler,
REVINVOKE, EmailListener:<imap or
pop3>:<user>@<host>, RFCListener@<ProgramID>,
FTPListener@<port>, HTTPListener@<port>
For each call into a subcomponent a "call subrecord" is attached to the above information:
Component type One of HTTPServer, FTPServer, SMTPServer,

BCServer, BCServerTC (BCServer with Guaranteed
Delivery), R/3, Database.
Component name In case of R/3: the alias. In case of a DB: the DB type.
In all other cases: the hostname and possibly the port
number.
Destination HTTPServer: the URL. FTPServer: the performed
command, directory and file name. SMTPServer:
Email address. BCServer and BCServerTC: the
invoked Service.
SAP-System: Function module name or IDoc type.

SAP AG
Database: the JDBC driver URL.

Calltime Time in ms, the Business Connector has been waiting
for a response from the component. (All these times
are added up to the WAIT time above.)
Sent Bytes Number of bytes sent. This field is used only in case
of HTTPServer, FTPServer, SMTPServer, BCServer
and BCServerTC.
Received Bytes Number of bytes received. This field is used only in
case of HTTPServer, FTPServer, SMTPServer,
BCServer and BCServerTC.
Number of calls Always 1.
Additional information Used only in case of Database: then it indicates,
whether an SQL statement or a stored procedure was
executed.
Mapping Inbound RFCs to SAP BC Services

The following is a simple tutorial that explains how to map inbound RFCs to SAP BC
Services on the SAP Business Connector Server. It describes an application in which the
SAP system requests an SAP BC Service to retrieve information about a product.
An SAP Business Connector inbound call is an outbound call from the SAP system’s point of view.
Creating a Function Module in an SAP System

Calling an SAP BC service from an SAP system requires, at a minimum, a remotely
callable function module with a defined signature (imports, exports, and tables). No
ABAP coding, screen development, or other work is required.
The following steps require that you have developer-level access on your SAP system and some
basic knowledge of the ABAP Workbench and Function Modules.
To create a function module in an SAP system
1 Using the SAP GUI, go to the ABAP Function Library. Choose Tools → ABAP
Workbench (transaction SE37).
2 Create a function group, e.g. Z_FG01 (Menu Goto/Function groups/Create
group)
3 Enter Z_BC_PRODUCT in field Function module. This is the name of your SAP
product retrieval function.
4 Choose Create.
5 Complete the following dialogs in accordance with the policies governing your
SAP development environment. The only aspect relevant to the SAP Business
Connector Server is the field Processing type. Select Remote Function Call
supported to allow this function to call externally to the SAP Business Connector
Server.
6 Define the import/export parameters of your function. Add an import named
SKU. You must provide a Reference field. Pick a character field with a length
greater than 5. For this example, use VBERROR-VARMSGVAL.

SAP AG
7 Add six exports: NAME, PTYPE, LENGTH, PRODUCT_WIDTH, PRICE and

AVAILABILITY. Again, you must provide Reference fields for each of the
exports. For this tutorial, use VBERROR-VARMSGVAL for these parameters.
8 Mark Pass value for all parameters.
The final screen should look like the following:
9 Save your function module and activate it.
Creating an Inbound Map

You need to associate a Service on the SAP Business Connector Server with the inbound
RFC. The following steps map the SAP BC Service tutorial.catalogue:getProductData
to inbound requests for Z_BC_PRODUCT. (This SAP BC service is provided with the
SAP Business Connector Server as a sample Flow Service.)
To create an Inbound Map

2 Choose the Lookup tab.
3 Select the name of the SAP server on which the Z_BC_PRODUCT function
resides.
4 Enter Z_BC_PRODUCT in the first Function Name field.
5 Choose Lookup.
6 You will see a screen titled RFC Signature for Z_BC_PRODUCT.
If not, you might not have defined your SAP Alias correctly. Review the steps in Creating an
RFC Destination on an SAP System on page 4-2.
7 Follow the link Define New Map corresponding to an inbound request (SAP
calling SAP BC).

SAP AG
8 On the resulting screen, enter the following values.

SAP BC Folder/Service names are case sensitive, as are the
parameters to the Flow Service.
Generate for <any listener A drop-down list with all listeners available for this
Listener specified and active> server alias. This allows the generation of map
signatures using the repository of the Listener which
is selected for all metadata lookups.
Package Default This is the name of the package into which the
Inbound Map will be generated. This does not need
to be the same Package in which the Service to
which you are mapping the RFC is contained.
Technically, an Inbound Map is a Flow Service that
starts with the name sap.inbound.<SysID>:<FM
name>. It should not be modified manually except in
the cases described further down.
ACL <None> Access Control List.

SAP AG
Server Alias (local) This is the name of the target BC.
Folder tutorial.catalogue This is the name of the Folder in which the Service to
which you are mapping the RFC is contained.
Service getProductData This is the name of the Service to which you are
mapping the RFC.
9 Press Save to add this map.
Testing the Product Retrieval Function

Use the following procedure to test the RFC Inbound Map you just created.
To test an inbound RFC

Use the following procedure to test the product retrieval function:
1 Ensure that an RFC Listener is running by doing the following:
a) Choose SAP from the SAP Business Connector navigation
panel.
b) Select the SAP Servers tab, if it is not already displayed.
c) Select the Listeners for your SAP server.
d) Verify that there are two green balls indicating that the
listener is started and active. If not, either wait for the
automatic listener restart or stop and start the listener by
clicking on the balls in the Started? column. If no listeners
appear in the list, refer to Configuring an RFC Listener in
SAP Business Connector Server on page 4-7.
2. In an SAP GUI session, go to the ABAP Workbench (transaction SE37) to test

your new function module.
3. Enter Z_BC_PRODUCT in field Function module and choose Sngl. test.
4. In the RFC target system field, type the Name of your RFC Destination (in this
example SBCCER). Also mark the “Upper/lower case” checkbox.
5. In the SKU field, enter a SKU. For this example, the SKU’s that are available
are A, B, C, D, or E. Case is important.
6. Execute the RFC by selecting the appropriate toolbar button or selecting
Execute from the Function modules menu or pressing F8.
7. You will receive the product data in your exports list similar as shown in the
following figure.
If you receive an error from the SAP Business Connector Server, make sure your map
is correct and that the tutorial.catalogue:getProductData Flow Service (WmSamples
package) is installed and functional.

SAP AG
Data returned by SAP BC service
Sending an RFC from an SAP System to SAP BC

Normally, the RFCs sent to the SAP Business Connector from an SAP System are mapped to
a specific SAP BC Service. However, in some cases, you might want to route an RFC through
the Partner Manager, but you can only route a mapped RFC if you provide a valid
SBCHEADER with your function call. To route RFCs through the Partner Manager, you must
include a header table that contains information that the Partner Manager uses to route the
RFC.
Before the Partner Manager can receive an RFC, you must define an RFC listener for the SAP
Business Connector. For instructions, refer to Configuring an RFC Listener in SAP Business
Connector Server on page 4-7.
To send an RFC to the Partner Manager, you must configure the SAP Server to use the SAP Business
Connector Server as an RFC destination. For instructions on how to create an RFC Destination, refer
to Creating an RFC Destination on an SAP System on page 4-2.
If no Inbound Map is defined, SAP BC will create a default Routing Rule based on the RFC
attributes of the connection:
Message Type Name of the function module

Sender System ID and Client Number
Receiver Program ID of the Listener

SAP AG
The SBCHEADER Table

You can write an ABAP wrapper that calls a function module through an RFC
destination and add an additional table to the call statement.
This table must not be defined in the function module interface.
The name of the table must be SBCHEADER and it must have the following structure.
Component Component type DTyp Length Dec. places Short text
NAME SBCNAME CHAR 32 0 SBC routing table, Keyfield
VALUE SBCVALUE CHAR 255 0 SBC routing table, value of Keyfield
This structure is defined in the SAP System starting with release 4.6A under the name
SBCCALLENV. If you do not have this structure in your system, please define a similar
one as above.
The header table can contain an arbitrary number of key/value pairs. If you want to pass
additional keys to the SAP Business Connector you can define your own name/value
pairs and insert them into the SBCHEADER table. You would read out these records
inside a java module in the SAP Business Connector with the following statements (case-
sensitive):
IDataCursor c = pipeline.getCursor();
Values sbcHeader = IDataUtil.getValues(c, "sbcHeader");
String property = sbcHeader.getString("fileName");
System.out.println("Property was "+property);
If you want the Partner Manager to invoke a routing rule to route the RFC, the header
table must contain the sender and receiver for the RFC. When determining the routing
rule to invoke, the Partner Manager uses the sender and receiver you specify in the header
table and uses the function module name in place of a message type.
To have the Partner Manager use a routing rule, include the following information in the
header table:
Key Value
sender Name of the sender. This name should match the name of a sender in the routing rule you
want the Partner Manager to use to route the RFC.
receiver Name of the receiving partner. This name should match the name of the receiver in the
routing rule you want the Partner Manager to use to route the RFC.
If you want to control the routing of an RFC from the SAP system directly (without
requiring a routing rule on the SAP Business Connector Server), you can include
transport information in the header table. The transport indicates where the Partner
Manager is to route the incoming RFC. When the Partner Manager receives an RFC that

SAP AG
specifies the transport, it does not invoke a routing rule but directly passes the RFC to the
specified transport. The transports that you can identify in a header table to dynamically
route an RFC through the Partner Manager are:
Route the RFC to B2B Service
Route the RFC to an SAP server
Post the RFC-XML to a URL
The following describes the key/value pairs you must specify for each transport you can
specify.
To route the RFC to a B2B Service, use the B2B Service transport.
Key Value
transport B2B Service
This value identifies the transport. Specify the value exactly as specified
above
serverAlias Name of the SAP Business Connector Server on which the service to invoke
resides. If the service resides on the server that routes the message, specify
(local). Otherwise, specify an alias for a remote server. For the routing to be
successful, the server routing the RFC must have the defined alias for the
remote server.
servicePath Name of the folder in which the service resides. The folder name is case
sensitive; use the exact combination of upper- and lower-case letters.
service Name of the service to which to pass the RFC. The service name is case
sensitive; use the exact combination of upper- and lower-case letters.
valueScope Where you want the Partner Manager to store the connection to the remote
server.
To save the connection in your own session, specify SESSION. Use
SESSION when the work being performed requires state be maintained.
To save the connection in a shared area, specify GLOBAL. Use GLOBAL
when the work being performed is stateless.
To route the RFC to an SAP System, use the RFC transport.
Key Value
transport RFC
This value identifies the transport. Specify the value exactly as specified
above.
server Name of the SAP server to which you want the RFC routed. This SAP server
alias needs to be defined on the Business Connector.

SAP AG
To post the RFC-XML to a URL, use the XML transport.
Key Value
transport XML
This value identifies the transport. Specify the value exactly as specified above.
url URL to which you want to post the RFC.
xmlType The XML format you want the Partner Manager to use for the http POST.
Specify SAP-XML if you want the data in an XML format that is compliant with
the SAP XML specification. Specify Values-XML if you want the data in
webMethods native XML format.
Username to supply for a username/password authentication challenge
httpUser
(optionally)
Password to supply for a username/password authentication challenge
httpPassword
(optionally)
For sending RFCs as bXML, please refer to page 6-11.
Example of Using an SBCHEADER Table
To test a function module with the function builder, write a wrapper module. The wrapper
module calls your RFC function module. The SBCHEADER table cannot be added in the
function builder and must not be part of the function interface of the module you want to call
remotely.
Note: normally you would not create such a wrapper module. Instead you would include
code similar to the following in your ABAP report at the point, where you want to call the
Business Connector.
The following example invokes the SBC_DEMO_COPY function module and echoes the
inputs it receives in the INPUT parameter. The input parameter DESTINATION is
interpreted as the RFC destination.
A wrapper for SBC_DEMO_COPY could look like this:
FUNCTION SBC_DEMO_WRAPPER.
*"------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING
*" VALUE(INPUT) TYPE CHAR255 OPTIONAL
*" VALUE(DESTINATION) TYPE CHAR32
*" EXPORTING
*" VALUE(OUTPUT) TYPE CHAR255
*" TABLES
*" SBCHEADER STRUCTURE SBCCALLENV
*"------------------------------------------------------------------
CALL FUNCTION 'SBC_DEMO_COPY' DESTINATION destination
EXPORTING
input = input
IMPORTING
output = output
TABLES
sbcheader = sbcheader
EXCEPTIONS

SAP AG
no_input_given = 1
communication_failure = 2 message msg
system_failure = 3 message msg
others = 4.
CASE sy-subrc.
WHEN 1.
output = 'Exception received: NO_INPUT_GIVEN'.
WHEN 2.
concatenate 'COMMUNICATION_FAILURE received:' msg into output separated
by space.
WHEN 3.
concatenate 'SYSTEM_FAILURE received:' msg into output separated by
space.
WHEN 4.
output = 'Exception received: OTHERS'.
ENDCASE.
IF sy-subrc NE 0.
WRITE output.
ENDIF.
ENDFUNCTION.
The following example illustrates how to route the SBC_DEMO_COPY function module
to the SAP Business Connector Server and have the Partner Manager invoke a Routing
Rule to route the message. When testing the function module SBC_DEMO_WRAPPER
from the SAPGui, provide the following input values:
INPUT Hello World!

DESTINATION SAPBC
SBCHEADER sender
CERMAND
receiver
DELL
SBC_DEMO_WRAPPER will then trigger the RFC call (SBC_DEMO_COPY) to the
specified RFC-Destination SAPBC (which corresponds to the name of the SAP BC
listener). In the SAP Business Connector Server, the Partner Manager invokes the Routing
Rule corresponding to the sender CERMAND, receiver DELL, and message type
SBC_DEMO_COPY. To determine how the Partner Manager routes SBC_DEMO_COPY
function module, you would need to inspect the corresponding Routing Rule that the
Partner Manager invokes.
The following example illustrates how to route the SBC_DEMO_COPY function module
to the SAP Business Connector Server and dynamically specify the routing information.
When testing the function module SBC_DEMO_WRAPPER from the SAPGui, provide
the following input values:

SAP AG
INPUT Hello ...!

DESTINATION SAPBC
SBCHEADER transport
RFC
serverName
CER
In this case, the SAP system routes the RFC to the specified RFC-Destination SAPBC.
In the SAP Business Connector Server, the gateway manger interprets the header table to
determine how to route the RFC. The Partner Manager routes the message to the SAP
server named CER using RFC. Note that CER must correspond to the name of an SAP
server that is configured in the SAP Business Connector Server.
Generating a record for a structure
This feature allows you to generate a record for any structure directly from the Function
Lookup or Table Lookup screen. If a service or record with the same name already exists
in the server namespace, an exception is raised. Thus, you won't overwrite existing nodes.
Generating a record

SAP AG
Generation parameters:
• Folder: folder in which the record will be saved

• Record: name of the generated record
• Package: package in which the record will be saved
Press the Save Button to generate a record with the given settings.
Working with different code pages

Use the following procedure if you handle data that is encoded (or that you want to encode
and send out) in a different encoding from your operating systems default code page.
To receive data from http, ftp, email or file

− You can use the Services pub.client:http, pub.client:ftp, pub.client:smtp and pub.file:getFile
to load a multi-byte document into the SAP Business Connector. Always use the
option loadAs=bytes.
− Convert the binary data using the Services pub.string:bytesToString or a combination of
pub.web:stringToDocument (also accepts bytes) and documentToRecord.
− Set the input parameter encoding to the Mime Encoding in which the bytes have been
encoded, i.e. one that is supported by the functions
sun.io.ByteToCharXXX.class, where XXX stands for the encoding (e.g.
ASCII, ISO2022 or SJIS).
To send out data via http, ftp, email or save it to file

− Ensure that you do not pass any String objects into the Services pub.client:http,
pub.client:ftp, pub.client:smtp or save a String into a file.
− Call pub.string:stringToBytes with the correct encoding parameter.
− Pass the bytes into http/ftp/smtp r into your Service which writes the file. (This service
should use java.io.FileOutputStream to write the file, not FileWriter.)
That way the message is sent out of SAP Business Connector with the proper
encoding.
You can also use the ftp or smtp transport easily as standard transport from the Partner Manager. For
further information, please refer to Example of Updating a Flow for FTP or Email Transport on page
5-19.
To encode data from SAP Systems
Use the following procedure if you are using pub.sap.rfc:encode.
To create the standard SAP XML you would use the service pub.sap.rfc:encode, which
handles encoding automatically.
For an example on how to use the encode Service, refer to the SAP Business Connector
Server Tutorial (see Related Documentation on page 1-2).

SAP AG
If you wish to create other XML-documents from SAP data, you should be careful to avoid
problems with code pages whenever you receive data from an SAP System (e.g. a response
to an outbound Remote Function Call or via an inbound call).
You need to set the encoding attribute in the XML-document manually:
Use the following steps if you are using pub.web:recordToDocument:
1 In the recordToDocument Service add the attribute @encoding of type

String as a child of the boundNode Record.
2 Insert the proper encoding value (e.g. Shift-JIS, if your target data will
be Shift-JIS encoded).
3 In the recordToDocument Service add a record list for your parameters
as a child of the boundNode Record.
4 Map your SAP parameters to the newly added record list.
If you have several SAP parameters, you need to add a record set for each one.
5 After the recordToDocument step, use pub.string:stringToBytes to

convert the UCS2 String into the correct binary encoding corresponding
to the value in the XML header “encoding” attribute.

SAP AG
Chapter 5: The Partner Manager
Introduction ....................................................................................... 5-2

Overview of the Partner Manager ....................................................... 5-2
Establishing Routing Rules ................................................................ 5-8
When a Routing Rule Is Not Defined ................................................ 5-15
Managing Routing Rules .................................................................. 5-16
Editing a Routing Service…………………………………………………5-18
Updating the Flow Associated with a Routing Rule............................ 5-18
Managing Transactions in the Message Store................................... 5-20
Configuration Parameters for the Partner Manager…………………...5-25

5-1
SAP SE
Introduction
This chapter describes the Partner Manager. It includes information about how to:
• Create and maintain routing rules
• Update Flow Services that process routing rules
• Manage transactions in the Message Store
For specific information about how to send IDocs and RFCs to the Partner Manager to be
routed, refer to “Chapter 7:Routing IDocs and XML messages to the Partner Manager” on
page 7-1.
Overview of the Partner Manager

The Partner Manager is a built-in facility of the SAP Business Connector that manages
the routing of messages. The Partner Manager determines how and where to route a
message based on routing rules that you define. Each routing rule is associated with an
SAP BC Flow Service that the Partner Manager generates based on the information in the
routing rule.
When the Partner Manager receives a message, it performs a routing rule lookup. After
locating the routing rule for the incoming message, the Partner Manager invokes the SAP
BC Flow Service that is associated with the routing rule.
The Partner Manager records each message it receives as a transaction in the Message Store.
The Partner Manager maintains the Message Store in the files xtn.log and xtn_audit.log in
the packages\WmPartners\config directory. You can view and manage the transactions
that the Partner Manager records in its Message Store.
Routing Rules
Routing rules indicate how a message is to be processed. Each routing rule is uniquely
identified by its sender, receiver, and message type. When the Partner Manager receives a
message, it performs a routing rule lookup to match the sender, receiver, and message
type of the incoming message with the sender, receiver, and message type of the existing
routing rules.
If a matching routing rule is found, the Partner Manager processes the message as the
routing rule indicates. If a routing rule is not defined for the message, the Partner
Manager generates an incomplete routing rule. When you complete the rule, subsequent
messages with the same sender, receiver, and message type are routed using the
completed rule.
The routing rule identifies a transport, which indicates how and where a message is to be
routed. The transports you can specify allow you to route a message to an SAP BC
service, send a message via e-mail, FTP a message, route an IDoc to an SAP server via
tRFC, route an RFC to an SAP server via RFC/tRFC, or post an SAP IDoc- or RFC-XML

SAP SE
to a URL Add-on packages like the MarketSet Connector offer additional transports, e.g.
for routing IDocs as XML messages to a Marketplace or Portal.
Components of a Routing Rule

The following shows a routing rule:
A routing rule contains:
1 Sender, receiver, and message type
2 Name of the service that is associated with this routing rule, an ACL which controls access to
the routing rule and a package, into which to generate this service
3 Pre-processing and post-processing SAP BC service (optional)
4 A flag that indicates, whether the "Confirm TID event" should be routed, too

SAP SE
5 A comment field for free use
6 Information about when and by whom this routing rule was last changed
7 How to route the message; that is, the transport
8 Additional Parameters based on the selected transport
Sender, Receiver, and Message Type

This information uniquely identifies a routing rule. The Partner Manager matches
incoming messages to these fields to locate the routing rule to invoke to process the
incoming message.
When a message is submitted, it must provide the Partner Manager with sender, receiver,
and message type values. The sender, receiver, and message type values contain the
following information:
Value Description
sender An arbitrary string that indicates who sent the message.
receiver An arbitrary string that indicates the message’s destination.
message type Identifies the type of information the message contains (e.g., a purchase order, a
credit memo, an invoice, and so forth)
For the Message types ORDERS and ORDRSP a demo mapping is shipped with SAP Business
Connector.
sap.demo.idoc.mappings:orders
sap.demo.idoc.mappings:ordrsp
These replace the sender/receiver information from the IDoc control record (SNDPRN and
RCVPRN) by partner information from the E1EDKA1 segment. If this is not desired, disable
this Content Based Routing from "Adapters  SAP  Routing".
You can write your own service for routing based on the fields which are used in your
environment. You can use Content Based Routing for this purpose (see page 8-24).
Refer to “Constructing an IDoc with the SAP Java ” on page 8-6 and Appendix D for the APIs
to parse the IDoc.
Using Wildcards as Routing Criteria

You can use a single asterisk character (*), known as a wildcard, for the Sender, Receiver,
and Message Type values in a routing rule. A wildcard matches any value that may be
submitted with an incoming document. You can:
Use a wildcard for the Sender parameter to serve as a “catch all” routing rule for a specific
message type. For example, suppose that you want to execute a particular routing rule

SAP SE
for all ORDERS documents from different companies. You don’t necessarily want to
define routing rules for each Company that might sent ORDERS to you, so you use the
wildcard character (*) for the Sender.
Use a wildcard for all parameters (Sender, Receiver, and Message Type) to serve as a “last
resort” routing rule. This routing rule will be executed when no other routing rules
match the incoming document.
Routing Rule Precedence

A routing rule is executed when its Sender, Receiver, and Message Type values match an
incoming document’s values. When one or more of those values is a wildcard (*), then the
routing rule is matched and executed based on its value precedence. See the following table
for the default match order. The most specific rule is matched first (and therefore
executed).
A rule with these
values is matched… Sender Receiver msgType
First fixed string fixed string fixed string
Second * fixed string fixed string
Third fixed string * fixed string
Fourth fixed string fixed string *
Fifth * * fixed string
Sixth * fixed string *
Seventh fixed string * *
Eighth (last) * * *
You can change this precedence order by modifying the file

packages\WmPartners\config\RoutingRulePriorityTemplate.cnf. After you
saved the file, you need to reload the WmPartners Package via "Packages 
Management".
Example
___________________________________________________________________________
Suppose that you have three routing rules set up with the following values:
Sender Receiver msgType
H9CCLNT800 partner1 ORDERS
* partner1 ORDERS
H9CCLNT750 * ORDERS

SAP SE
If a message arrives with the following values:

Sender = H9CCLNT800
Receiver = partner1
msgType = ORDERS
it will be routed according to the first routing rule, even though the second rule
would also match. Analogously a message with the values
Sender = H9CCLNT750
Receiver = partner1
msgType = ORDERS
would be routed according to the second rule, not the third.
Name of the Service that corresponds to the Routing Rule

The Partner Manager suggests a name to use for the Flow Service that processes the
routing rule ("main flow"). In general, you can accept this suggestion. Only if your
sender, receiver or message type values contain characters, which may not be part of a
filename in the file system (e.g. \ / : * ? " < > | on Windows), you should change this
name, so that the definition files for that Flow Service can be saved to file system.
Note: If you specify the name of an already existing Flow Service here, it will be
overridden!
The Partner Manager then generates the Flow Service based on the fields you specify in
the routing rule. You select the package, into which this Flow Service should be put, and
the ACL determining, which SAP BC users are allowed to execute this routing rule.
After you create a routing rule and the Partner Manager generates the Flow Service, you
can update the Flow Service using the SAP Business Connector Developer. For more
information, refer to “Updating the Flow Associated with a Routing Rule”on page 5-18.
Pre-Processing SAP BC Service

Optionally, you can specify a pre-processing Flow, Java, or C/C++ Service. The main
Flow Service invokes the pre-processing service before it invokes the Outbound Process
of the selected transport.
The pre-processing service is passed the incoming message. It can perform any
processing, including modifying the message to be routed. When the pre-processing
service is complete, the main Flow Service invokes the Outbound Process of the selected
transport.

SAP SE
Post-Processing SAP BC Service

When you define a routing rule, you can optionally instruct the Partner Manager to execute a
post-processing service after routing a document to its destination.
When you specify the name of a post-processing service in the routing rule, the Partner
Manager executes that service after the Outbound Process has completed.
Note: Pre- and post-processing services are services that you create to perform any
work that must be executed immediately before or after the Partner Manager sends a
document out.
The use of these services is purely optional.
Forward "Confirm TID event"

If this flag is activated, the Partner Manager tries to forward the Confirm TID event, which is
triggered by the tRFC protocol, to the same destination, where the document went. What then
happens depends on the used transport.
Some transports ignore this (an FTP server for example probably wouldn't know, what to do
with this anyway). In this case at least the status in the Message Store is set to "Confirmed".
But the transports, which have an SAP system or another Business Connector as destination,
confirm the TID on the destination system. This may become important in those cases, where
the final receiver of the message is again an SAP system. For each tRFC it receives, an SAP
system keeps an entry in a "check table" (ARFCRSTATE), to protect against duplicate
processing of the same document. Only after the sender has indicated via Confirm TID, that it
will never again try to post this document, the receiving system can safely remove this entry
from its check table.
Up to release 4.6 the Business Connector would not forward this Confirm TID event, so the
check table in receiving SAP systems would keep growing, which may become a performance
problem, if large numbers of messages (IDocs) are exchanged via the internet. But with this
feature it is now possible to clean up this check table in scenarios like
SAP A  BC A --Internet BC B  SAP B
or
external client  BC  SAP,
if the external client uses the new API offered by the Partner Manager. (See Appendix D,
wm.PartnerMgr.gateway.runtime:confirmTID.)
Comment
You can use this field for your own purposes, as needed.
Last changed information

The Partner Manager keeps track of who last changed a routing rule and when this was down.
The time is formatted as defined by "Settings  Logging  Log Timestamp Format". (Note

SAP SE
that the WmPartners Package needs to be reloaded, before changes to that setting become
effective.)
How to Route the Message (Transport)

The transport indicates how the Partner Manager is to route the message (for example,
route it to an SAP BC service or FTP it to a host). The transport can be one of the
following:
B2B Service Routes the message to an SAP BC service on the local SAP Business
Connector Server or on a remote SAP Business Connector Server.
Email Outbound Service Sends the message in an e-mail message.
FTP Outbound Service FTPs a message to a host.
ALE (R/3 IDoc) Routes an IDoc to an SAP server via tRFC.
RFC Routes an RFC to an SAP server via RFC or tRFC.
XML Posts an SAP bXML, IDoc- or RFC-XML to a URL.
BAPI Routes a BAPI to an SAP Server via RFC or tRFC
Based on the transport you select, the Partner Manager displays additional fields required by the
selected transport.
The following transports are able to support the "Confirm TID event" feature: B2B Service, ALE,
RFC, XML, BAPI.
Note: Add-on packages to the Business Connector (like the MarketSet

Connector) may define additional transports, which then also become available
via the dropdown list in the routing rule display.
Establishing Routing Rules

The easiest way to create routing rules is, to just send the messages, you will be using in
production, to the Business Connector and have him generate the necessary routing rules
automatically. (See next section.) But you can also create routing rules manually as
follows. Use the following procedure to define a routing rule.

SAP SE
To define a routing rule
1 Choose the Routing entry under Adapters from the SAP Business Connector
Server navigation panel.
2 Select the Routing Rules link, if is not already selected.
The Partner Manager displays the View Routing Rules screen. The top part of
the screen allows to restrict the display of routing rules by setting certain search
filters using the wildcards? for exactly one arbitrary character and * for any
number of characters. You can also use the character ^ for negating a filter. (For
example if you want to view only those routing rules, whose sender has an 'A' as
second letter, you would set the sender filter to ?A*. If you want to select all
routing rules, whose sender does not start with a B, use the filter ^B*.) The
middle part of the screen lists the existing rules that match with the search filter.
3 Below the list of existing rules are three input boxes. Type the name of the
sender in the first box, the name of the receiver in the second box, and the
message type in the third box.
4 Select Add. The Partner Manager displays the Edit Routing Rule screen.
5 Set the Routing Rule Flow parameters as follows:
Key Value
ACL ACL to restrict execution permissions for this

routing rule to certain SAP BC or SAP users
Main Flow Service Name you want to use for the Flow Service that
represents this routing rule. By default, the
Partner Manager creates a name that
incorporates the sender, receiver, and message
type information. If you are satisfied with the
default name, leave the name as is.
Package Package for the Flow Service. Select the package
in which you want the service to reside from the
drop-down list.
The SAP Business Connector Server creates a file using the Main
Flow Service name you specify. If the sender, receiver, or message
type values contain characters that your file system does not support,
be sure to change the name that the Partner Manager creates. For
example, if the message type is XML\PurchaseOrder, you would want to
change the ‘ \ ‘ to a different character (e.g. XML_PurchaseOrder).
6 If you want to use a pre-processing or post-processing SAP BC service, specify the
fully qualified name of the service in the Pre/Post-Processing Service field. The
service name is case sensitive. Be sure to use the exact combination of upper-
and lower-case letters when specifying the service name.
7 Select one of the following transports from the Transport field and specify the
additional information that is specific to the type of transport you select. For
information about the additional parameters that you need to supply for each
transport, refer to the page indicated below.
Select this transport… To Page

SAP SE
B2B Service Route the message to an SAP BC 5-10

service.
Email Outbound Service Send the message in an e-mail 5-11
message.
FTP Outbound Service FTP the message to a host. 5-12
ALE (R/3 IDoc) Route an IDoc to an SAP server 5-12
RFC Route an RFC to an SAP server 5-13
XML Posts an SAP bXML, IDoc- or RFC- 5-13
XML or any arbitrary XML document
to a URL.
BAPI Routes a BAPI to an SAP server 5-14
8 Press Save.
9 Enable the routing rule by clicking on the enabled column.
Transport: B2B Service

Use this transport to route messages to another SAP BC service that executes on the local machine or on a
remote SAP BC Server.
The entire pipeline is submitted to the specified B2B service. If you connect to a remote SAP BC Server, you
should edit the main Flow Service of this routing rule and add a MAP step before the call to the
OutboundProcess, where you drop all unnecessary parameters from the pipeline, so that the amount of
data, which is send over the network, is as small as possible.
The B2B Service Transport supports the "Confirm TID event".
Set the Configure B2B Service parameters as follows:
Key Value
Server Alias SAP Business Connector Server on which the service to invoke resides. If
the service resides on the same service as the Partner Manager that is
routing the message, select (local). If the service resides on a remote server,
select the name of the SAP BC Server from the drop-down list.
The drop-down list contains the names of remote SAP BC Servers that you
have defined. For information about defining aliases for remote SAP BC
Servers, refer to the SAP Business Connector Server Administrator’s Guide.
Folder Name of the Folder in which the service resides. The Folder name is case
sensitive; use the exact combination of upper- and lower-case letters as
defined on the SAP BC Server that you specified in the Server Alias field.
Service Name of the service to which the message is to be passed. The service
name is case sensitive; use the exact combination of upper- and lower-case
letters as defined on the SAP BC Server that you specified in the Server Alias
field.

SAP SE
Scope Used only if the target Service is invoked on a remote SAP BC Server.
Specifies whether you want the connection to the server to be stored in your
session or in a shared location. If the work being performed requires that
state be maintained, select SESSION. If the work being performed is
stateless, select GLOBAL.
When sending an IDoc or an RFC between two SAP Business Connectors using B2B Service
Transport, enter pub.sap.transport.ALE or pub.sap.transport.RFC as Folder and InboundProcess
as Service.
If the receiving Business Connector is of a lower release than 4.8 and you are sending an IDoc,
you also need to edit the main flow of this routing rule and add the following extra step, as older
SAP BC releases do not understand the new internal IDoc format.
SAP BCs of release 4.6 or lower expect the two tables IDOC_CONTROL_REC_40 and
IDOC_DATA_REC_40. Therefore add the step pub.sap.idoc:iDocToTables.
SAP BCs of release 4.7 expect the IDoc to be in “IDoc Library 1.0” format. Therefore add the
step pub.sap.idoc:convertToIDoc10.
Transport: Email Outbound Service
Use this transport to e-mail a message to a trading partner.

If you use this transport, you must update the Flow Service that the Partner Manager generates for
the routing rule and define the content, which is to be mailed. For information about how to
update the routing rule, refer to Example of Updating a Flow on page 5-19.
Transport the contents of data/content to the specified email address, where data is a Record (a
Values/IData object) and content is an object element of data. If your document is to be routed through the
Email Transport:
− It must be in the form of a String, a byte[ ], or an InputStream.
− You must map the document to data/content before invoking the Email OutboundProcess.
− The default file name of the attachment is <tid>.xml, if the document came in with a transaction ID
(e.g. via tRFC), and ATT<n>.txt, were n is a continuously increasing number, otherwise. You can
override this default at runtime via the variable data/filename.
Set the Configure Email Outbound Service parameters as follows

Key Value
SMTP Host Host name of the SMTP server to which is to relay the e-mail message.
Content Type Content type the Partner Manager should specify for the attachment of the e-
mail, which contains the document. For example, specify application/x-edi-message
for an EDI message.
From E-mail address that you want the Partner Manager to use for the sender of the
e-mail message, for example, [email protected].
To E-mail address to which you want the Partner Manager to send the e-mail
message, for example, [email protected].
CC Optionally, the e-mail address to which you want the Partner Manager to send a
complimentary copy of the e-mail message, for example,
[email protected].

SAP SE
BCC Optionally, the e-mail address to which you want the Partner Manager to send a
blind complimentary copy of the e-mail message, for example,
[email protected].
Subject Optionally, the subject you want the Partner Manager to use for the e-mail
message.
Body Optionally, a note for the receiver you want the Partner Manager to put into the
body of the email.
Transport: FTP Outbound Service
Use this transport to FTP a message to a location.

If you use this transport, you must update the Flow Service that the Partner Manager generates for
the routing rule and define the content to be FTPed. For information about how to update the
routing rule, refer to Example of Updating a Flow on page 5-19.
Transport the contents of data/content to the specified file location, where data is a Record (a Values/IData
object) and content is an object element of data. If your document is to be routed through the FTP transport:
− It must be in the form of a String, a byte[ ], or an InputStream.
− You must map the document to data/content before invoking the FTP OutboundProcess.
Set the Configure FTP Outbound Service parameters as follows

Key Value
Host Name Host name of the remote FTP server.
Port Number Port number on which the remote FTP server listens for incoming requests.
User Name Username the SAP Business Connector Server must supply to connect to the
remote FTP server.
Password Password the SAP Business Connector Server must supply to connect to the
remote FTP server.
File Path Directory path and file name on the target machine where the message is to
be placed.
Transfer Type Optional: active or passive depending on whether you want the Business
Connector to use active or passive FTP.
File Name Optional. A file name under which the data should be stored on the FTP
server. If no name is specified, the Partner Manager uses the file name
<tid>.xml, if the document came in with a transaction ID (e.g. via tRFC),
or ftpfile<n>.data, where n is a continuously increasing number,
otherwise.
Timeout Optional. Time (measured in seconds) to wait for a response from the ftp
server before timing out and aborting the request. Default is to wait forever.
Transport: ALE (R/3 IDoc)

Use this transport to route an IDoc to an SAP server via tRFC.

SAP SE
Before you can route an IDoc to an SAP server, you must define the SAP server. For instructions, refer to
“Defining SAP Servers” on page 3-4.
Set the Configure ALE Transport parameters as follows:

Key Value
Specify SAP Name of the SAP server to which you want the Partner Manager to route the
Destination IDoc. Select an SAP server from the drop-down list.
The drop-down list contains the names of servers that are defined in the SAP
Business Connector Server. For instructions on how to define an SAP server,
refer to “Defining SAP Servers” on page 3-4.
Transport: RFC
Use this transport to route an RFC to an SAP server via RFC or tRFC.
Set the Configure RFC Transport parameters as follows:
Key Value
Destination RFC. Select an SAP server from the drop-down list.
The drop-down list contains the names of servers that are defined in the SAP
Business Connector Server. For instructions on how to define an SAP server,
refer to “Defining SAP Servers” on page 3-4.
Transport: XML
Use this transport to post an SAP IDoc-XML or RFC-XML to a URL.

Set the Configure XML Transport parameters as follows
Key Value
Specify URL URL to which you want the Partner Manager to post the XML message.
XML dialect Choose between the XML dialects SAP-XML, bXML, Values-XML, Arbitrary
XML or SOAP XRFC (XRFC with SOAP envelope).
If you select SAP-XML the content type is set to ‘application/x-sap.idoc’
(respectively ‘application/x-rfc’). Therefore, the receiving server has to
understand this content type. (This can be overridden using the following flag.)
If ‘Arbitrary XML’ is selected, the transport expects the XML document as
string in the variable xmldata. In that case you need to modify the routing rule
flow similarly to the Email or FTP cases. Add the necessary steps to create the
XML string from the input data and then map it to the xmldata parameter.
Use text/xml as Flag that allows you to overwrite the content type of bXML, SAP-XML and
content type SOAP XRFC to text/xml, if set to true. The checkbox is disabled for other
dialects.

SAP SE
Use utf-8 as encoding Flag that allows you to force the renderers of bXML, SAP-XML and SOAP
XRFC to use the encoding utf-8, if set to true. The checkbox is disabled for
other dialects.
Use BAPI Format Set this flag, if you want to use the BAPI XML format. (This field is only active
when using the bXML dialect.)
Business Object The name of the business object to which the call should be mapped. This
value is case-sensitive. (Available only when using the bXML dialect and the
BAPI format.)
BAPI The name of the BAPI method, to which the call should be mapped. This value
is case-sensitive. (Available only when using the bXML dialect and the BAPI
format.)
Replace invalid If this flag is set, non-printable characters (characters in the range 0x00 –
characters 0x1F) are replaced with a ‘#’ character instead of being escaped with an
escape sequence like for the NUL character. Note: the three characters
TAB, LF and CR are always escaped. (Available only when using SAP-XML,
the bXML dialect or SOAP XRFC.)
Use XML 1.1 If this flag is set, version=”1.1” is used in the XML preamble. Note: in XML 1.1,
non-printable characters, except for the NUL character, are always escaped
instead of replaced. (Available only when using SAP-XML, the bXML dialect or
SOAP XRFC.)
User An optional parameter that allows you to specify a username for authentication
(optional) on the remote Web system.
Password An optional parameter that allows you to specify a password for authentication
(optional) on the remote Web system.
When sending an IDoc between two SAP Business Connectors via XML transport, use
http://<sapbc>:<port>/invoke/pub.sap.transport.ALE/InboundProcess as URL.
When sending an RFC to a second SAP BC that does not have an outbound map for the function
module in question, use
http://<sapbc>:<port>/invoke/pub.sap.transport.RFC/InboundProcess as URL.
Transport: BAPI
Set the Configure BAPI Transport parameters as follows
Key Value
Destination BAPI. Select an SAP server from the drop-down list.
The drop-down list contains the names of servers that are defined to the SAP
Business Connector Server. For instructions on how to define an SAP server
to the SAP Business Connector Server, refer to “Defining SAP Servers” on
page 3-4.
Processing no restrictions Caller may decide to send both synchronous and

restrictions asynchronous calls.

SAP SE
synchronous only Caller may only send calls without a transaction ID.
Messages with a transaction ID (asynchronous
messages) are rejected and an XML error message is
returned.
asynchronous only Caller may only send calls with a transaction ID.
Messages without a transaction ID (synchronous
messages) are rejected and an XML error message is
returned.
When a Routing Rule Is Not Defined

When the Partner Manager receives a message for which it cannot locate a routing rule, it
logs the message in its Message Store and throws an Exception.
In addition, the Partner Manager generates an incomplete routing rule for the message.
An administrator should complete the routing rule definition. Subsequent messages with
the same sender, receiver, and message type are automatically routed using the completed
rule.
The following procedure describes how to complete the routing rule.
To complete a routing rule that is “Not Ready” (indicated by a red ball)
1 Select the Routing entry under Adapters from the SAP Business Connector Server
navigation panel.
2 Select the Routing Rules tab, if it is not already selected.
The Partner Manager displays the View Routing Rules screen. The middle part of
the screen lists existing rules.
The incomplete routing rule has the status “Not Ready” (indicated by the red ball).
3 Press the icon for the rule you want to complete. The Partner Manager displays
the Routing Rules screen.
4 Set the Flow Information, Invoke Pre-Processing, and Transport parameters as
described in Establishing Routing Rules on page 5-8.
5 Choose Save.

SAP SE
6 Enable the routing rule by pressing No in the Enabled? column.
The next time the Partner Manager receives a message that has the sender,
receiver, and message type identified in the routing rule that you just completed, the
Partner Manager will trigger this routing rule.
Managing Routing Rules

After you define routing rules, you can:
• Display the routing rules that have been established
• Update information for routing rules
• Delete routing rules
Displaying Routing Rules

Perform the following procedure to view the existing routing rules.
To view routing rules
1 Select the Routing entry under Adapters from the SAP Business Connector Server
navigation panel.
2 In the top part of the screen you can specify search filters for the parameters sender,
receiver and message type to restrict the number of routing rules which are displayed. In
the filter you may include the wildcards * to match an arbitrary number of characters and
? for exactly one character. You can also start the filter with the character ^, which will
form the logical complement of the search expression. (E.g. the search will return all
routing rules that do not match the filter.) Leaving a field empty is equivalent to specifying
a *.
3 Press the Update button to view the new selection of routing rules.
If you have routing rules that use a wildcard * as sender (or receiver or message type) and you
want to display only those, you cannot take "*" as the search filter for sender, as this would select
everything. Instead set the search filter to "?". This will select all routing rules, whose sender
value is exactly one letter long, and this will most probably be the set of routing rules, whose
sender equals "*".
Updating Routing Rules

After you create a routing rule, you can update information for the routing rule if
necessary. You cannot change the sender, receiver, or message type information of a
routing rule.
When you update the routing rule, the Partner Manager updates the Flow Service that
corresponds to the routing rule. The changes you make to the routing rule through the Routing Rule

SAP SE
screen affect only the first operation in the Flow Service. If you have added additional operations
to the flow, they will not be altered. For more information about updating the Flow Service, refer
to Updating the Flow Associated with a Routing Rule on page 5-18.
Perform the following procedure to update a routing rule.
To update a routing rule
1 Select the Routing entry under Adapters from the SAP Business Connector
2 Choose the Routing Rules tab to open the View Routing Rules screen.
3 Press the icon in the Edit column for the routing rule you want to edit. The
Partner Manager displays the Routing Rule screen.
4 Make changes as necessary. For information on what you can specify, refer to
“Establishing Routing Rules” on page 5-8.
5 After you make your changes, choose Save.
Disabling Routing Rules

Use the following procedure to disable a routing rule. When you disable a routing rule, all
routing service and rule information is preserved until you re-enable it. But incoming messages
for this sender/receiver/msgType combination will not be routed by the Business Connector as
long as the routing rule is disabled.
To disable a routing rule
1. Start the SAP BC Server Administrator. See the SAP BC Administrator’s Guide if you
need procedures for this step.
2. On the Adapters menu, click Routing. The View Routing Rules screen appears.
3. Locate the rule that you want to disable. Under Enabled?, click Yes until it turns to
No.
Deleting Routing Rules

When you no longer need a routing rule, you can delete it. Perform the following
procedure to delete a routing rule.
When you delete a routing rule, the Partner Manager deletes the SAP BC Flow Service that is
associated with the routing rule.
To delete a routing rule

SAP SE
2 Select the Routing Rule tab if it is not selected.

3 Locate the routing rule you want to delete, and press the icon in the Delete
column.
Editing a Routing Service

When necessary, you can edit a routing service with SAP BC Developer to incorporate
additional operations before or after the transport delivers the document. For example,
you might want to insert flow-control operations (for example, LOOP or BRANCH
operations) around the pre-processing service, or you might want to include some error-
handling operations immediately after the transport service.
Guidelines to Follow When Editing a Routing Service

When you edit a routing service, keep the following points in mind:
1 Do not add any flow operations before the first MAP operation.
2 Do not modify the pre/post-processing service’s label property (if a pre/post-processing service
exists in the flow).
3 Do not modify the transport service’s label property.
Updating the Flow Associated with a Routing Rule

When you create a routing rule, the Partner Manager generates a Flow Service. If you
want, you can modify the Flow Service that the Partner Manager generates. For example,
you might want to update the Flow Service to digitally sign a message before it is routed.
If you use the FTP Outbound Service or Email Outbound Service transport, you must
update the Flow Service and provide data for the file to be FTPed or the attachment to be
mailed. For example if you want to FTP an IDoc in EDI flat file format, you would insert
the step pub.sap.idoc:encodeString and map its result into the data input of the
FTP:OutboundProcess. If the outbound data should be an XML document, you would use
pub.sap.idoc:encode instead, or your own mapping service that creates the format of your
choice. See the example below for detailed instructions of how this is done.

SAP SE
Use the SAP Business Connector Developer to update the Flow Service. Be sure to abide
by the following rules for updating the Flow Service:
1 Do not add any flow operations before the first MAP flow operation.
2 Do not update the flow operation for the pre/post-processing service, if it exists.
3 Do not update the flow operation for the outbound transport service.
Example of Updating a Flow for FTP or Email Transport

When you create a routing rule that uses the FTP Outbound Service or Email Outbound
Service transport, you must update the flow created for the routing rule to make the Flow
Service functional. From the SAP Business Connector Developer, make the following
changes to the routing rule flow to make it functional.
To update the flow for FTP or Email Transport for sending an IDoc
1 Add a flow operation to invoke the pub.sap.idoc:encode service after the first
MAP flow operation.
This service converts the IDoc to an XML string, which is the format the FTP
and Email Outbound Transport service can understand. Alternatively, you can
use any other Service that transforms the IDoc data into the desired format in
string or byte array form.
2 Select the last flow operation, Transport Service: INVOKE Outbound Process.
3 Select the Pipeline tab if it is not already selected.
4 Expand the data variable in Service In to display its structure.
5 Add a map to link the xmlData variable in Pipeline In to the content variable in
Service In.

SAP SE
6 Save the flow.
Example of Digitally Signing a Message

This shows a flow that has been updated to digitally sign a message before it is routed to
its destination by the transport service. See also the Built-In-Services Guide, chapter
Security Services, for details.
Managing Transactions in the Message Store

The Partner Manager logs each message it receives as a transaction in the Message Store.
Each message is associated with a transaction id that uniquely identifies the transaction. If
the Partner Manager receives a message without a transaction ID, it creates one for the
message.

SAP SE
Use the Transactions screens to view and manage the transactions that the Partner Manager
records in its Message Store. Here you can view transactions and their processing log as
well as delete transactions that are no longer needed.
The Administrator should manually follow-up transactions in status ‘Rolled back’ as
follows:
Try to find and eliminate the reason of failure and then
 Re-send the transaction from SM58, if it originally came from an SAP system
 Ask your partner to re-send the transaction, if it originally came in via FTP or HTTP.
Viewing Transactions in the Message Store

You can view transactions that the Partner Manager currently has in its Message store.
Perform the following procedure to view a list of transactions.
To view the transactions in the Message Store
2 Select the Transactions tab if it is not already selected. The Partner Manager
displays the Transactions screen that lists the transactions.
3 Optionally you can specify query settings to restrict the number of displayed
transactions or to specifically search for certain transactions. You can specify a
time frame (upper limit and lower limit) in which the transaction has been
created, a search filter for TID, sender, receiver and message type and restrict
to a certain state.
The date format of the upper and lower limit fields has to be exactly like the
Server-wide date format specified under Settings  Logging  Log Timestamp
format. The list of transactions is also using this format
The search filters may include the wildcards * for an arbitrary number of
characters and ? for exactly one character. In addition, you can start the filter
with the ^ character, which will negate the expression. (I.e. in that case the
search will return all transactions that do not match this particular filter.)
All conditions are combined with a logical and.
The Partner Manager displays transactions in pages of 50, to avoid a timeout or
out-of-memory of the web browser in case there are a large number of
transactions in the message store. This page size can be changed also. The
current selection of transactions (according to the query settings) and their
current sort order is kept until the Update Search is executed again, even if you
switch between different screens or log off from the Server and later log in again.
4 In the end press the Update Search button to display the selection of transactions.

SAP SE
To view detail information for a transaction, press on the transaction ID in the TID column.

SAP SE
This screen allows you to view the details of each transaction, including the sender,
receiver, message type, transaction ID, time when this transaction was first received by the
BC, current state, the time when this state was set, last error (if any), and an audit trail that
shows state changes, error messages and the various steps that have processed the message.
The Current State field contains the transaction state. The information in this field
corresponds to the different states of the tRFC protocol. If the message was not received
via tRFC but via a different protocol (like http), the Partner Manager tries to "imitate" the
tRFC status handling, but the meaning of the single states is slightly different in this case.
The following describes the valid states of a tRFC transaction:
Status Meaning (tRFC) Meaning (other protocols)

SAP SE
Created The sender has sent a transaction ID, which was The sender has sent a transaction ID and
accepted by the BC. (No data sent yet.) data, which was forwarded to the Partner
Manager.
Executed The data has been sent and processed ok. The Partner Manager has located and
executed a routing rule successfully.
(Meaning there was no error message, but
also no success message from the
OutboundProcess of the transport used in
this routing rule.)
Rolled Back Execution of the transaction has failed. The sender Execution of the transaction has failed. The
may retry the transaction again at a later time. sender may retry the transaction again at a
later time.
Committed The sender has acknowledged, that he knows, that The OutboundProcess of the transport
the transaction executed successfully. used in this routing rule returned a success
message.
Confirmed The sender has "promised" never to send this This is used, only if the external client
transaction again. So the TID may be deleted, as invokes the service
there is no need any more to protect against wm.PartnerMgr.gateway.runtime:con
duplicate processing of the same transaction. firmTID after the transaction has been
executed successfully. In this case and if
the transport supports it, the "Confirm
event" has been forwarded to the final
receiver, so that it is able to clean up its
ARFCRSTATE table and remove the TID
from it.
If the storing of message bodies has not been disabled on this Business Connector
(server.cnf parameter watt.PartnerMgr.noMsgStorage), it is also possible to view the
message body of the transaction from this screen.
If the data was received in any arbitrary format, the message can be viewed as a Values
document. If it came in as an RFC, RFC-XML, IDoc or IDoc-XML, it can be viewed as
XML, and if it came in as an IDoc or IDoc-XML, it can even be viewed in form of an
HTML table.
Deleting Transactions from the Message Store

If the Message Store contains transactions that are no longer needed, you can delete them.
To delete transactions from the Message Store
2 Select the Transactions tab if it is not already selected.

SAP SE
3 If you want to delete just a single transaction, press the icon in the Delete
column for that transaction.
4 If there is a certain selection of transactions, you would like to delete -- for
example "all transactions in state Confirmed that came from sender HUGO
between 2003-01-26 08:00:00 and 2003-05-09 15:36:00" -- you can do so by
completing the query settings as described above under ’Viewing Transactions
in the Message Store’, then pressing Update Search and finally Delete
Selection. The total number of transactions that will be deleted, can be seen in
the field Currently Selected. But careful: if you haven't refreshed the page in
your browser for quite some time, and someone else has meanwhile also
created a selection of transactions, you will delete his selection instead of the
previous one made by yourself. This is, because the selection is kept Server
wide and not per user.
5 Finally, you can delete everything by pressing the Delete All button.
Automatic Cleanup of the Message Store

If the growth of the message store becomes a problem in your system, you ought to consider
scheduling a periodic job that periodically purges the message store of transactions, which are
no longer needed. The following procedure can be used for this.
To purge certain transactions from the message store periodically
1 In the Administrator UI go to Server  Scheduler and schedule the Service

wm.PartnerMgr.xtn.Sweeper:sweepTRX.
2 Pass the following parameters to the sweepTRX service using Add Value.
For this parameter…. Specify…
onState The transaction state. (Created, Executed, Rolled back, Committed or

Confirmed)
elapsedTime The number of minutes that the transaction has been in status onState
maxTrxCount The maximum number of transactions to delete each time that

sweepTRX runs
The maxTrxCount parameter can be used to control the pace of your maintenance jobs
without putting too much load on the Server at one single time. It is also a good idea to
schedule the job at times, when there is not much load on the Server.
Configuration Parameters for the Partner Manager

The Partner Manager reacts to the following configuration parameters, which can be set
in the file <installDir>/config/server.cnf. Some of these influence the performance.

SAP SE
1. watt.PartnerMgr.noMsgStorage
If this parameter is set to "true", the Business Connector will not save the message body of
incoming transactions.
2. watt.PartnerMgr.routeOnly
If this parameter is set to "true", the Business Connector will neither maintain any transaction
and status information in the message store, nor save the message body of incoming
transactions.
3. watt.PartnerMgr.flushPeriod
This parameter specifies the time period in minutes, how often the Partner Manager will flush
yet unsaved changes in the transaction Cache to the file system. Default is every 5 minutes.
4. watt.PartnerMgr.flushMaximum
This parameter specifies how many unsaved transactions the "flushing thread" should save to
the file system during one execution. It will stop after this number, even if there are still more
unsaved transactions in the Cache. This is offered for performance reasons, so that the server
will not spend too much time non-stop in Cache flushing. Default is 200.
5. watt.sap.monitorIDocs
If this parameter is set to "true", the Business Connector will link the IDoc packet's TID with
the DOCNUMs of the IDocs in that packet, so that a later ALE IDoc Trace or SYSTAT01
update will be possible. See the section "Using the ALE Monitoring Features via the SAP BC"
in chapter 8 for more information.

SAP AG
Chapter 6: Setting up Routing for BAPIs
Inbound Call to an SAP System .................................................. 6-2

Outbound Call from an SAP System ........................................... 6-8

6-1
SAP AG
Inbound Call to an SAP System

Setting up the SAP Business Connector and the BAPI Transport
Inbound messages in the new BAPI-based XML format can be easily dispatched using
the SAP Business Connector routing tool.
For each BAPI sent to the Partner Manager via XML, a corresponding entry in the
routing table should exist. If no entry exists, the message won’t be executed, and the
SAP Business Connector will automatically generate a routing rule for this message.
This routing rule has to be completed and activated by an administrator.
The message type used in the Partner Manager for BAPIs is constructed from the
concatenation of the business object name and the BAPI name, which are separated by a
dot. (The syntax is <Business Object>.<BAPI method name>).
After a routing rule has been automatically generated, it is not yet ready for processing.
This is indicated by the red symbol in the Status column. By choosing Edit you can
complete this routing rule.
The only transport applicable to inbound BAPI calls is the BAPI transport as shown in the
screenshot.

SAP AG
This transport has two parameters:

SAP Destination: You can select a target SAP system from the drop-down list. The
message will be sent to this SAP system.
Processing restrictions: Some BAPIs can be called both synchronously and
asynchronously. Callers can choose how they want to execute a call by specifying a
transaction ID in the XML header (see the documentation of the BizTalk Envelope,
BizTalkEnvelopeSpec.pdf). If you want to allow only one specific type of call (for
example for performance reasons only asynchronous calls, or for administration
reasons only synchronous calls), you can define restrictions using the drop-down list:
no restrictions Caller may decide to send both synchronous and asynchronous calls
Caller may only send calls without a transaction ID. Messages with a
synchronous only
transaction ID (asynchronous messages) are rejected and an XML
error message is returned
asynchronous only Caller may only send calls with a transaction ID. Messages without a
transaction ID (synchronous messages) are rejected and an XML error
message is returned
After completing the form, select Save. The routing rule is now displayed as Ready,
indicated by the green symbol in the routing table.
Posting BAPI-based XML to the SAP Business Connector

To apply the routing rules, the XML message should be posted to the Partner Manager
for BAPIs, this is the service pub.sap.transport.BAPI:InboundProcess.
Execute an HTTP post operation to
http://<host>:<port>/invoke/pub.sap.transport.BAPI/InboundProcess
In the HTTP body, an XML message specifying the BAPI-call as described above must
be sent. You have to use the HTTP content type application/x-sap.busdoc
when posting to the BAPI InboundProcess.
POST /invoke/pub.sap.transport.BAPI/InboundProcess HTTP/1.0
Content-Type: application/x-sap.busdoc
User-Agent: Java1.1.8
Host: localhost:5555
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-length: 817

<header>
<delivery>
<message>
<messageID>0A125F1315B3D24B0000001E</messageID>
<sent>2000-06-20T09:58:00</sent>
</message>
<to>
<address>urn:sap-com:logical-system:SAPSYS0001</address>
</to>
<from>
<address>urn:sap-com:logical-system:BUSCON0001</address>
</from>
</delivery>

SAP AG
</header>
<body>
<doc:CompanyCode.GetList xmlns:doc="urn:sap-
com:document:sap:business" xmlns="">
<CompanyCodeList>
<item>
<COMP_CODE></COMP_CODE>
<COMP_NAME></COMP_NAME>
</item>
</CompanyCodeList>
</doc:CompanyCode.GetList>
</body>
</biztalk_1>
Posting RFC Based IFR-compatible XML Messages

SAP Business Connector supports the XML format for use with arbitrary RFC function
modules. By using the content-type application/x-sap.busdoc, which is also
used for BAPIs (see above), you can easily post RFC function calls to the SAP Business
Connector.
These XML messages must provide a BizTalk XML envelope (for further information,
see the documentation about the BizTalk Envelope, BizTalkEnvelopeSpec.pdf). The call
of the corresponding business document for the RFC function can be put in the body of
the BizTalk message.
By using the BizTalk XML envelope and the above content-type, you also enable the
support for the application-specific XML error documents, which are defined in the SAP
Interface Repository.
You can post to the URL corresponding to a generated RFC Outbound Map for the
function module, or to the general RFC InboundProcess:
http://<server>:<port>/invoke/pub.sap.transport.RFC/InboundProcess
Transaction Control
You can control whether the BAPI should be called synchronously via RFC or
asynchronously via ALE by the <referenceID> element in the BizTalk header.
If the <referenceID> element is specified and contains a valid SAP transaction ID
(TID), the BAPI outbound process automatically chooses the ALE format, otherwise, if
the element is omitted, the message will be processed synchronously. For both
synchronous and asynchronous calls, technical processing errors are reported by an XML
response document containing a fault descriptor.
BAPI XML Transaction Commit

When running a BAPI call with SAP Business Connector in some cases the SAP System
expects a commit command to execute the call. To commit the transaction directly over
HTTP, do the following:
1. Call the lockSession service with an empty POST over HTTP
http://localhost:5555/invoke/pub.sap.client/lockSession
2. Call the BAPI in the same session using HTTP.
3. Commit the service with an empty POST using HTTP.
http://localhost:5555/invoke/pub.sap.bapi/commit
4. Release the session by sending an empty POST using HTTP.
http://localhost:5555/invoke/pub.sap.client/releaseSession

SAP AG
Note: With the HTTP requests in steps 2-4 you need to resubmit the cookie, which you
got with the response in step 1. Otherwise the BC cannot assign these requests to the
same user session and the “commit” does not know, which transaction to commit.
Synchronous Calls
Application-level responses to synchronous XML requests consist of a response business
document in the HTTP response.
The response business documents for synchronous calls are documented in the SAP
Interface Repository and contain a serialization of all exporting and changing parameters
of the BAPI or FM.
Example:
• Sending a synchronous call to a SAP System
• Business Connector returns a response business document

SAP AG
Asynchronous Calls to SAP Systems

An asynchronous call can be executed by specifying a transaction ID in the BizTalk
header of the XML document. The XML element used is the <referenceID>-
element (see description of the BizTalk XML envelope) in the <state>-section of the
BizTalk header (inside <to>).
A transaction ID should be a global unique ID expressed in hexadecimal letters and 24
letters long, for example 0A11449F652C394A34DE042F.
If an asynchronous request can be transmitted without errors to the SAP System, the
SAP Business Connector will return a BizTalk envelope with an empty body as
confirmation document. If there were any processing errors, the body will contain a fault
descriptor element.
The result of an asynchronous call can be checked inside the target system by using the
ALE monitoring services (transaction BD87). Please refer to your SAP System
documentation for further information on ALE services.
Example:
• Sending an asynchronous request to a SAP System by specifying a transaction ID

SAP AG
• Receiving an XML confirmation document
• Checking the correct application-level processing inside the target SAP System
(transaction BD87 in a SAP system of release 4.6A or higher. In older systems
use the IDoc list transaction WE05):

SAP AG
Outbound Call from an SAP System

Overview
SAP Systems communicate with the SAP Business Connector on an implementation-level
when calling BAPIs. This means, they try to call the implementing function module
directly via RFC or, if asynchronous processing is used, they send an IDoc.
The SAP Business Connector has a built-in converter to automatically rebuild the original
object-based BAPI method call and represent it as an XML message. Therefore, the XML
transport can handle these messages using the XML dialect bXML, to build a BAPI-style
XML message.

SAP AG
To process this function, you have to create a routing rule, which maps the SAP call to the
XML transport.
The message types used in the Partner Manager for routing BAPIs are based on the BAPI
implementation. This means, for routing messages from an SAP System:
• the RFC (function module) name of the BAPI implementation is used for
synchronous calls
• the corresponding ALE message type is used for asynchronous calls
These ALE message types can be found using the built-in BAPI browser.
When setting up the routing rule, you have to specify the name of the business object and
BAPI to which the call should be mapped.
Setting Up Routing Rules for the XML Transport

To enable this function, you will first have to setup an RFC Listener for the relevant SAP
Systems (see Chapter 4:)
You can prepare a routing-rule fragment by executing the corresponding call inside your
SAP System with your Business Connector as the destination. If no routing rule has yet
been defined, a new one will be created.

SAP AG
To edit this Routing Rule, perform the following steps:
1 Select the Routing tab on the SAP Business Connector Administration

web page.
2 Select Edit for the new routing rule (new routing rules are indicated by a
red symbol in the Status column).
3 Select XML in the Transport field to choose the XML transport.
4 Select the XML Dialect bXML.
5 Enter a URL as destination of the XML call. To post the XML to another
SAP Business Connector, you can post the message to its BAPI inbound
process. For this, you can use the URL.
http://<host>:<port>/
invoke/pub.sap.transport.BAPI/InboundProcess.

SAP AG
6 Select the checkbox Use BAPI format to specify that the call should be
represented as a BAPI in XML.
7 Enter the name of the corresponding business object.
8 Enter the name of the corresponding BAPI method.
9 Optionally you can specify a username and password for user
authentication on the remote host.
Note: as of release 4.6, you can select additional options for the XML transport
configuration:
Use text/xml as content type: Flag that allows overwriting the

•
content-type of bXML, SAP-XML to text/xml, if set to true. The
checkbox is disabled for other dialects.
• Use utf-8 as encoding: Flag that allows forcing the renderers of
bXML, SAP-XML to use the encoding utf-8, if set to true. The
checkbox is disabled for other dialects.
• SOAP XRFC can be selected as additional XML dialect. This is
equivalent to XRFC (RFC-XML) with a SOAP envelope (higher
than SOAP 1.1).
As of Release 4.8.1, there are two more options that can be used:
• Replace invalid characters: invalid characters are replaced with #
instead of with an escape entity.
• Use XML 1.1: use XML version=”1.1” instead of “1.0”.
See the description of the XML Transport above for details.
RFC Based XML Messages Using IFR Format

You can also generate XML calls for RFC function modules that are based on the IFR
XML format. To do this, you only have to select bXML as XML dialect in the routing
rules for RFC messages, and deselect the Use BAPI format option.
Dynamic Routing Using the XML Transport

It is not always necessary to specify routing rules. If you want to call a BAPI from an
ABAP report in your SAP system, you can also add the SBCHEADER parameter to your
function module call.
This parameter can be filled with key-value pairs that describe in detail how the message
should be routed. BAPI-calls can be routed only to the XML transport. To do this, use the
following key pairs in the SBCHEADER table:
Name Value
Transport XML
The destination URL for the HTTP post operation
url
bXML
xmlType
httpUser An optional parameter that allows you to specify a username for authentication on
(optional) the remote web system
httpPassword An optional parameter which allows you to specify a password for authentication
(optional) on the remote web system

SAP AG
useBAPI Set this value to ‘ON’ if you want to use the BAPI XML format. If you omit this
value or set it to something different than ‘ON’, the message will be sent as RFC
based XML in a BizTalk XML envelope
object The name of the business object, to which the call should be mapped. This value
has to be case-sensitive
bapi The name of the BAPI method, to which the call should be mapped. This value is
case-sensitive
xsender A value that should be put in the header field <from> <address>. See senderType
for further details
senderType An optional format descriptor, defining the sender address type. Default is
(optional) ‘LogSys’ for logical systems. Logical system names are automatically converted to
an URN by an SAP defined schema. Alternatively, you can set senderType.
xreceiver A value that should be put in the header field <to> <address>. See receiverType
for further details
receiverType An optional format descriptor, defining the receiver address type. Default is
(optional) ‘LogSys’ for logical systems. Logical system names are automatically converted to
an URN by an SAP defined schema. Alternatively, you can set receiverType.
useTextXml Flag that allows to overwrite the content-type to text/xml, if set to true (for SAP-
XML and bXML).
useUTF8 Flag that allows to force the renderers to use the encoding utf-8, if set to true (for
SAP-XML and bXML).
For sending RFC based XML messages, only the first five parameters are supported.
You can specify these parameters in your ABAP RFC call as follows:
DATA header like SBCCALLENV occurs 1 with header line.

*... some code lines omitted
CALL FUNCTION 'BAPI_COMPANYCODE_GETLIST'
DESTINATION 'SAPBC'
IMPORTING
RETURN = returnCode
TABLES
COMPANYCODE_LIST = companyCodes
SBCHEADER = header
.
Example: Calling a BAPI Synchronously from an SAP System

This example demonstrates how to invoke a call of the BAPI
CompanyCode.GetDetail from an SAP System to the Web via XML.
As the BAPI will be sent to the Partner Manager, you need to specify some information to
enable correct routing. For this purpose, you should use the parameter SBCHEADER
when calling the RFC function module from the SAP System.
Preparations:
Set up an RFC Listener for the SAP System on your SAP Business Connector as
described in Chapter 4:.
Set up a corresponding RFC destination on your SAP System for your Business
Connector using transaction SM59 as described in Chapter 4:.
Create a program ZBAPIDEMO in the SAP System using transaction SE38.

SAP AG
You can enter the following source code:
REPORT ZBAPIDEMO.
*variable companyCodes will take the application result
data companyCodes like BAPI0002_1 occurs 1 with header line.
*variable header gives Business Connector instructions for routing
data header like SBCCALLENV occurs 1 with header line.
*variable returnCode takes the processing information after the
*synchronous call
data returnCode type BAPIRETURN.
*Fill the SAP Business Connector routing instructions
header-name = 'sender'.
header-value = 'SAPSYS'.
append header.
header-name = 'receiver'.
header-value = 'SAPBC'.
append header.
*Execute the RFC with destination SAPBC

CALL FUNCTION 'BAPI_COMPANYCODE_GETLIST'
*->SAPBC should be maintained in SM59 as alias to Business Connector
DESTINATION 'SAPBC'
IMPORTING
RETURN = returnCode
TABLES
COMPANYCODE_LIST = companyCodes
SBCHEADER = header[]
.
*process the BAPI-Return parameter
if not returnCode is initial.
write: / 'BAPI return parameter:'.
write: / ' Code: ' , returnCode-CODE.
write: / ' Message: ' , returnCode-MESSAGE.
endif.
*display the application result
loop at companyCodes.
write: / companyCodes-COMP_CODE, ' ', companyCodes-COMP_NAME.
endloop.
Before executing this report, you should define a routing rule using the XML transport.
You can send the XML message to any server that is able to process the HTTP Post
message and send back a correct response. In this example, the call will be sent back to
the locally installed SAP Business Connector to demonstrate its inbound XML processing
capabilities.
Prepare a routing rule for the RFC call:

Log on to your SAP Business Connector Administration UI.
Select the Routing tab on the SAP Business Connector Administration UI.
In the input fields at the bottom of the page, enter the following data:
• Sender: SAPSYS.
• Receiver: SAPBC.
• Message-type: BAPI_COMPANYCODE_GETLIST.

SAP AG
• Press the Add rule button.

• In the field transport, select XML.
• Specify a URL for the target system. To test the functionality using your local SAP
Business Connector’s inbound processing, enter:
http://localhost:5555/invoke/pub.sap.transport.BAPI/InboundProcess
(note that in some cases you have to adjust the port 5555 to your current settings).
• Select XML dialect bXML.
• Enable the Use BAPI mode checkbox.
• Enter CompanyCode as business object.
• Enter GetList as BAPI.
• Press the Save button.
To handle the inbound XML message, which the local SAP Business Connector is going to send to
itself, you have to specify a second routing rule for the BAPI:
Log on to your SAP Business Connector Administration UI.
Select the Routing tab on the SAP Business Connector Administration UI.
In the input field at the end of the page, enter the following data:
• Sender: SAPSYS.
• Receiver: SAPBC.
• Message-type CompanyCode.GetList.
In the transport field, select BAPI.
Select the SAP Server to which the message should be routed from the drop down list.
Choose the Save button.
When executing the program in the SAP System, the SAP Business Connector will send
the HTTP Request to the remote host. This request will look similar to the following one:
POST /invoke/pub.sap.transport.BAPI/InboundProcess HTTP/1.0

User-Agent: Mozilla/4.0 [en] (WinNT; I)
Accept: image/gif, */*
Host: localhost:90
Content-type: application/x-sap.busdoc
Cookie: ssnid=553891555519
Content-length: 817

<header>
<delivery>
<message>
<messageID>0A125F1315B3D24B0000001E</messageID>
<sent>2000-06-20T09:58:00</sent>
</message>
<to>
<address>urn:sap-com:logical-system:SAPBC</address>
</to>
<from>
<address>urn:sap-com:logical-system:SAPSYS</address>
</from>
</delivery>

SAP AG
</header>
<body>
<doc:CompanyCode.GetList xmlns:doc="urn:sap-
com:document:sap:business" xmlns="">
<CompanyCodeList>
<item>
<COMP_CODE></COMP_CODE>
<COMP_NAME></COMP_NAME>
</item>
</CompanyCodeList>
</doc:CompanyCode.GetList>
</body>
</biztalk_1>
When using the SAP Business Connector as the remote partner as described above, the
BAPI will be executed in the selected system, the exporting and changing parameters
will be put in an XML response document and sent back to the calling SAP System. The
report will then display the parameters received from the remote system, which in this
case is a list of company codes.
Example: Calling a BAPI Asynchronously from an SAP System

This example demonstrates how to call a BAPI asynchronously from an SAP System
over the Web.
For this purpose, you have to create an ABAP program inside the SAP System. This
program calls the proxy function module to generate an ALE message for a BAPI. After
performing a COMMIT WORK command, the SAP System will generate an IDoc
through the ALE service layer and send it to the SAP Business Connector. There the
IDoc will be transformed into the original BAPI representation and sent as XML using
HTTP to any remote web system.
While BAPI function module names usually start with the prefix BAPI_, the corresponding ALE
proxies are usually named equally with the prefix ALE_.
To get to the example to work, you should set up your SAP System for ALE processing
as described in the SAP System documentation and in this guide.
When defining the partner profile for the outgoing IDoc in the SAP System, you have to
ensure, that the option Transfer IDoc immediately is selected, as the BAPI conversion
tool on the SAP Business Connector does not support IDoc packages.
Create the following report in your SAP System to test the BAPI conversion with the
BAPI Bank.Create (available as of SAP release 4.6C).
REPORT ZALEDEMO.
parameters receiver like BDI_LOGSYS-LOGSYS.
parameters country like BAPI1011_KEY-BANK_CTRY default 'DE'.
parameters bankkey like BAPI1011_KEY-BANK_KEY default '34981255'.
data: receivers like BDI_LOGSYS occurs 0 with header line,

address like BAPI1011_ADDRESS.
*prepare the distribution information

move receiver to receivers-LOGSYS.
append receivers.
*prepare the BANK addres parameter

address-BANK_NAME = 'Demo Bank'.
address-REGION = 'BW'.
address-STREET = 'Neurottstr. 16'.

SAP AG
address-CITY = 'Walldorf'.
address-SWIFT_CODE = 'ABCDDE12'.
address-BANK_GROUP = 'SB'.
address-BANK_NO = '12345678'.
address-ADDR_NO = '123'.
*send data to ALE

CALL FUNCTION 'ALE_BANK_CREATE'
EXPORTING
BANKCTRY = country
BANKKEY = bankkey
BANKADDRESS = address
TABLES
RECEIVERS = receivers
EXCEPTIONS
ERROR_CREATING_IDOCS = 1
OTHERS = 2
.
IF SY-SUBRC NE 0.
write: / 'IDoc could not be created'.
ELSE.
write: / 'IDoc successfully created'.
ENDIF.
*trigger processing
commit work and wait.
Create Routing Rules for the asynchronous BAPI call

You can create routing rules similar to those described in the synchronous example.
1 Log on to your SAP Business Connector Administration UI.
2 Select the Routing tab on the SAP Business Connector Administration
web page.
3 In the input field at the end of the page, enter the following data:
• Sender: enter the logical system of the sending system.
• Receiver: enter the logical system of the target system.
• Message-type BANK_CREATE.
4 In the transport field, select XML.
5 Specify an URL for the target system. To test the functionality using your local SAP
Business Connector’s Inbound processing, enter:
http://localhost:5555/invoke/pub.sap.transport.BAPI/InboundProcess
(note that in some cases you have to adjust the port 5555 to your current settings).
6 Select XML dialect bXML.
7 Enable the Use BAPI mode checkbox.
8 Enter Bank as business object.
9 Enter Create as BAPI.
10 Press the Save button.

SAP AG
Handling the Inbound XML Message

To handle the inbound XML message, which the local SAP Business Connector is going to send
to itself, you have to specify a second routing rule for the BAPI:
1. Log on to your SAP Business Connector Administration web page
2. Select the Routing tab on the SAP Business Connector Administration
web page.
3. In the input field at the end of the page, enter the following data:
• Sender: enter the logical system of the sending system.
• Receiver: enter the logical system of the target system.
• Message-type Bank.Create.
4. In the field transport, select BAPI.
8 Select the SAP Server to which the message should be routed from the
drop-down list.
9 Press the Save button.
When executing the report, you have to enter a RECEIVER. This should be the name of
the logical system you have defined for your SAP Business Connector.
When executing the report in the SAP System, the SAP Business Connector will transmit
the XML document via HTTP. The XML document would look as follows (names of
logical systems depend on your system configuration):

<header>
<delivery>
<message>
<messageID>0A125F1315B3A11B00000035</messageID>
<sent>2000-06-07T09:22:40</sent>
</message>
<to>
<address>urn:sap-com:logical-system:SAPSYS001</address>
</to>
<from>

SAP AG
<address>urn:sap-com:logical-system:BUSCON001</address>
</from>
</delivery>
</header>
<body xmlns="">
<doc:Bank.Create xmlns:doc="urn:sap-com:document:sap:business">
<BankKey>34981243</BankKey>
<BankCtry>DE</BankCtry>
<BankAddress>
<BANK_NAME>Demo Bank</BANK_NAME>
<REGION>BW</REGION>
<STREET>Neurottstr. 16</STREET>
<CITY>Walldorf</CITY>
<SWIFT_CODE>ABCDDE12</SWIFT_CODE>
<BANK_GROUP>SB</BANK_GROUP>
<POBK_CURAC></POBK_CURAC>
<BANK_NO>12345678</BANK_NO>
<POST_BANK></POST_BANK>
<BANK_BRANCH></BANK_BRANCH>
<ADDR_NO>123</ADDR_NO>
</BankAddress>
</doc:Bank.Create>
</body>
</biztalk_1>
You can check the correct processing of your BAPI-call in the IDoc status monitor.

SAP AG
In the target SAP System, you can also inspect the correct processing using the ALE
status monitor (transaction BD87 in SAP release 4.6C; IDoc lists can also be displayed
with transaction WE05). If any application errors occurred, they are listed in the IDoc
monitor.

SAP AG

SAP AG Routing IDocs and XML messages to the Partner Manager
Chapter 7: Routing IDocs and XML messages to the

Partner Manager
Introduction ................................................................................. 7-2

Sending IDocs with ALE from an SAP System to SAP BC............. 7-2
Posting IDoc- and RFC-XML (XRFC) Documents ......................... 7-5
Transmitting IDocs between two Business Connectors…………….7-7
 Posting arbitrary XML documents……………………………………. 7-8
 Mapping IDocs to Other Formats.................................................7-10
 Pre-Routing Mechanisms for content-based routing with IDocs….7-23
 Using the ALE Monitoring Features via the SAP BC.....................7-26

7-1
SAP AG
Introduction
For the Partner Manager to route IDocs and RFCs, you must send the IDocs and the RFCs
to the Partner Manager. The following lists the typical ways that you can send IDocs and
RFCs to the Partner Manager.
Method Refer to page
Sending an RFC from an SAP System to SAP BC 4-24
Sending IDocs with ALE from an SAP System to SAP BC 7-2
Posting IDoc- and RFC-XML (XRFC) Documents 7-5
Transmitting IDocs between two Business Connectors 7-7
Posting arbitrary XML documents 8-7
When the Partner Manager receives the IDoc or RFC, it matches the sender, receiver, and
message type associated with the IDoc or RFC to its routing rules. When it locates a
matching routing rule, this is invoked to route the IDoc or RFC.
Sending IDocs with ALE from an SAP System to SAP BC

The Partner Manager receives IDocs from an SAP server, if the tRFC
(INBOUND_IDOC_PROCESS or IDOC_INBOUND_ASYNCHRONOUS) has no
Inbound Map associated with it. When the Partner Manager receives the IDoc, the sender,
receiver and message type are extracted from the IDoc itself. The Partner Manager uses
this information when determining where to route the IDoc.
Before the SAP Business Connector can receive the IDoc, you must define an RFC listener for
the SAP Business Connector Server. For instructions, refer to “Configuring an RFC Listener in
SAP Business Connector Server” on page 4-74.
For information about how to map the IDoc information into another format for use by another
application, refer to “Mapping the data in an IDoc” on page 7-18.
To set up an SAP server to send IDocs to the SAP Business Connector Server, use the
SAP GUI to perform the following steps:
Step Description
1 Create an RFC Destination on the SAP server
2 Define a logical port
3 Create a partner (also known as a logical system)
4 Create a partner profile
5 Create a distribution model for the partner and message type

SAP AG
Step 1 Create an RFC Destination on the SAP System
For instructions on how to create an RFC Destination, refer to Creating an RFC

Destination on an SAP System on page 4-2.
The RFC Destination is the low-level technical item by which the Business Connector
is known to the SAP system.
Step 2 Define a logical port
A logical port is an abstraction that allows differentiating between several technical

transport layers used for IDoc communication. For example, the SAP system can
send out IDocs as a flat file in the file system, via HTTP or via a tRFC call. In this
case we will chose tRFC as transport protocol and link the port to the Business
Connector’s RFC destination.
You can define a unique logical port using transaction WE21 (Alternatively, use the
following menu path to do this: Main screen  Tools  Business Communication
 IDoc-Basis  IDoc  Port Definition).
1 Select the Transactional RFC tree item and choose the Create button.
2 Choose New Entries button in the toolbar.
3 Either choose your own descriptive port name or let the system generate one.
4 Enter the IDoc version you want to send via this port, the RFC destination you
just created, and a short description of your logical port, then save the
information.
Step 3 Create a partner (also known as a logical system)
A logical system represents the communication partner, to which the ALE layer
sends its IDocs. A logical system usually collects several partner profiles for different
IDoc message types. This allows specifying different processing instructions for
different IDoc message types that go to the same business partner.
You can create a partner (logical system) using transaction SPRO_ADMIN.
Alternatively, use the following menu path to do this: Main screen -> Tools ->
AcceleratedSAP -> Customizing -> Project Management. (Or use transaction SALE
and continue with step 2 below.)
1 Choose SAP Reference IMG.
2 Expand the following nodes: Basis Components Application Link Enabling
(ALE)  Sending and Receiving Systems -> Logical Systems Define Logical
System. (You can also use transaction SALE and select the path described
above, starting with Application Link Enabling (ALE).
3 Press on the green checkmark beside Define Logical System.
4 Select the New Entries button.

SAP AG
5 Enter an informative name for your partner and provide a short description. After
saving the partner information, assign it to a transport request.
Step 4 Create a partner profile
A partner profile links three pieces of information together: the logical system, the
ALE message type and the port. In other words, the partner profile defines, which
transport channel (port) to use, when a certain IDoc (message type) is sent to a
certain business partner (logical system). For example, a business partner may
require, that ORDERS IDocs are sent to one of his systems via RFC, while INVOIC
IDocs are sent to another system of his in flat file format.
Use transaction WE20 to create a partner profile (alternatively, use the following
sequence to do this: Main screen  Tools  Business Communication  IDoc-
Basis  IDoc  Partner profile).
1 Select the LS (logical system) partner type in the tree view and press the Create
button in the toolbar.
2 Enter the partner you created in step 3 in the partner field and save the
partner profile.
3 Click the Insert entry button below the outbound parameter table control.
4 Enter the message type of the IDoc, (e.g., MATMAS).
5 Enter the logical receiver port you created in step 2 and enter the basic type
of the IDoc, (e.g., MATMAS03).
6 Save the outbound parameter.
Step 5 Create a distribution model for the partner and message type
After you define a partner and a partner profile, you can create a distribution model
that triggers the creation of a communication IDoc.
If you are using SAP System 4.5 or earlier, you can use transaction BD64 to create
the distribution model or alternatively, use the following sequence to do this: Main
screen  Tools -> Business Framework  ALE  Customizing.
1 Open the Cross-Application Components folder, then the Distribution (ALE)
folder, then the Distribution Customer Model folder in the tree view. Press on the
green hook beside Maintain customer distribution model directly.
2 Create a new model using Model  Create.
3 Add a message type to your model, enter the sender in the dialog box (e.g.,
ALRCLNT000), enter the receiver (e.g., the logical system defined in step 3 ),
and the message type (e.g., MATMAS).

SAP AG
If you are using SAP System 4.6 or later, you can use BD64 or alternatively, the
following procedure:
1 In the Main screen, choose Tools  AcceleratedSAP  Customizing 
Project Management.
2 Choose SAP Reference IMG.
3 Expand the following nodes: Basis Components  Distribution (ALE) 
Modeling and Implementing Business Processes  Maintain Customer
Distribution Model.
4 Press on the green hook beside Maintain Customer Distribution Model
(transaction BD64).
5 Change into the edit mode.
6 Choose Create model view.
7 Enter a short text string and a technical name for your new model view.
8 Select your new model view in the tree Distribution Model and choose Add
message type.
9 In the dialog box, enter the sender (e.g., ALRCLNT000), the receiver (e.g., the
logical system defined in step 3 ), and the message type (e.g., MATMAS).
Posting IDoc- and RFC-XML (XRFC) Documents

If you submit an IDoc- or RFC-XML document in one of the following ways, they will
automatically be passed to the Partner Manager for routing.
Posting an IDoc-XML Document from an HTTP Client

Use the following guidelines to submit an IDoc-XML document via any HTTP client:
POST /invoke/pub.sap.transport.ALE/InboundProcess HTTP/1.1\r\n

Host: <hostname of client>\r\n
Content-Type: application/x-sap.idoc\r\n
Authorization: Basic <base64-encoded user:password>\r\n
Content-Length: <number of bytes in XML document>\r\n
\r\n
<?>xml version="1.0"?>
<ORDERS01>
...
</ORDERS01>
The value for the content length has to be replaced by the actual length of content.
The example shows an IDoc-XML document. For RFC-XML you need to change the URL to
/invoke/pub.sap.transport.RFC/InboundProcess and the content-type to
application/x-sap.rfc.
To simulate an HTTP client for testing purposes, you can use the service pub.client:http.
1 Using the SAP Business Connector Developer, navigate to the
service pub.client:http located in the WmPublic package.
2 Choose Test  Run.

SAP AG
3 Specify the URL of the IDoc-XML handler service. For example,

http://localhost:5555/invoke/pub.sap.transport.ALE
/InboundProcess.
4 Specify Post as the method.
5 Add one entry in the field headers:
Name: Content-type
Value: application/x-sap.idoc
6 Copy a sample IDoc-XML document into the field

data -> string
Posting an IDoc via FTP
Perform the following steps to FTP an IDoc- or RFC-XML document to the Partner
Manager:
open <BC host> <port of ftp listener>

username: Administrator
password: manage
cd ns/pub/sap/transport/ALE/InboundProcess
bin
put example.idocxml
The FTP client should check the return code to find out whether processing of the
document was ok.
It is important that the file name of the document ends with .idocxml.
If you are posting RFC-XML, the file name needs to end with .xrfc and the term ‘ALE’ in the
file path needs to be changed to ‘RFC’.
Posting an IDoc in an email message
To send an IDoc- or RFC-XML document to the Partner Manager in an email message,

put the document into an attachment whose name ends with .idocxml or .xrfc
respectively. In the subject line of the email specify:
pub.sap.transport.ALE:InboundProcess or
pub.sap.transport.RFC:InboundProcess

SAP AG
Posting an IDoc from a Web Browser

To post an XML document into the Partner Manager, you can submit it via a Web page, or you
can create an HTTP client that performs the post. This section describes how to post IDoc- and
RFC-XML documents from a web browser.
You can submit an IDoc-XML for any IDoc type to the Partner Manager from a Web
browser using the following page:
http://<SAP BC-server>:<port>/SAP/Submit_IDocXML.html
This demo page can be used as a test tool. If you plan to submit IDocs
from an HTML form, you can use this page as sample code.
Transmitting IDocs between two Business Connectors

To send IDocs over the Internet, use the following procedure to
establish the connection between two Business Connectors (i.e. your
own and the one of your Business Partner).
1 On the sending Business Connector create a Remote Server that points to the
receiving Business Connector. For more information on creating Remote
Servers see “Setting up Aliases for SAP BC Remote Servers” in the SAP BC
Administration Guide, chapter 7. If you are inside a firewall, make sure that your
HTTP proxy server is configured under Settings  Proxy Servers.
2 Send a test IDoc from the SAP Server to your SAP BC or create the routing rule
manually.

SAP AG
3 Complete the routing rule specifying the following parameters:

• Transport: B2B Service
• Alias: <Remote Server name of your trading partner>
• Folder: wm.PartnerMgr.gateway.transport.B2B
• Service: InboundProcess
• Scope: <choose default value>
4 Edit the Flow Service corresponding to the routing rule and drop all unnecessary
parameters in a MAP located before the step invoking the outbound service.
This reduces the amount of data sent over the network. Normally only these
parameters need to be sent to the remote BC server: $tid, sender, receiver,
msgType, iDocList.
If the receiving SAP BC is of release 4.7 or lower, you need to invoke another
service before the outbound service: pub.sap.idoc:iDocToTables (remote
server is 4.6 or lower) or pub.sap.idoc:convertToIDoc10 (remote server is
4.7). These services convert the IDoc into the format expected by older
releases.
One more tip to increase performance: ask your communication partner to also drop all
unnecessary parameters at the end of the routing rule service which receives this document. This
reduces the amount of data sent back in the response. Normally no parameters need to be returned
to the sending BC server.
Posting arbitrary XML documents
Instead of using pre-defined XML dialects like IDoc-XML and RFC-XML, it is also
possible to forward arbitrary XML documents to the Partner Manager by using the
Inbound Process mechanism of the XML transport.
For this purpose, you can configure a so-called inbound routing info service for your
XML dialect. This service should implement the specification
pub.sap.transport.XML:xmlRoutingInfo, using the following parameters:
Input Parameters
This key Must specify…
boundNode This record contains the XML document as it would look like
after having been processed by pub.web:documentToRecord.
Your service should extract the routing data from your specific
documents.
Return Values

SAP AG
sender Sender used for finding the matching Routing Rule in the
Partner Manager.
receiver Receiver used for finding the matching Routing Rule in the
Partner Manager.
msgType Message type used for finding the matching Routing Rule in
the Partner Manager.
$tid (optional) Transaction ID found in the document, if client wants to
execute a transaction once and only once. If no $tid exists, the
Partner Manager will generate one.
$routeOnly (optional) If this parameter is set to true, the PartnerManager, will only
route the message, without creating a transaction.
To configure the Inbound Process mechanism of the XML transport, perform the
following steps:
1 Create an inbound routing info service for the XML transport. It should
extract all required parameters from the incoming XML documents so
that the Partner Manger can route these documents.
2 After having implemented this service, you still have to make it known
to the XML transport. Go to "Routing ..." in the main Administrator
screen of the Business Connector.
3 In the Routing screen click on Transports, which will give you a list of
all Transports:
4 Click on XML, and the configuration screen is shown to you. Provide

the full service name in the input field, and push the save button:

SAP AG
Now you are ready to do routing using XML Inbound Process for arbitrary XML
documents. Whenever an XML document is posted to the URL
/invoke/pub.sap.transport.XML/InboundProcess with content-type text/xml, it
will be routed by the Partner Manager.
Mapping IDocs to Other Formats

If you need to use the information contained in an IDoc in documents of another format,
you build an SAP BC Flow Service that “maps” the information from fields in the IDoc
to the variables used by the other application. For example, to transfer a purchase order
from an ORDERS02 IDoc to an EDI system, you create a Flow Service that maps
information from the IDoc fields to fields within the EDI system’s purchase-order record.
Then, you define a routing rule that triggers this Flow Service.
The following instructions will show you how to do this in detail:
Stage Description
1 Create the routing rule that routes the IDoc to the SAP BC service that maps the IDoc
information.
2 Create an empty Flow Service, which will later execute the mapping.
3 Create a Record Definition for your IDoc
4 Transform the IDoc to hierarchical format (i.e., transform it to a boundNode variable).
5 Map the IDoc fields to other variables in the pipeline.
6 Test the Mapping Service.
7 Remove Development Flow Operations from the Service

SAP AG
Creating a Routing Rule that points to a Flow Service
Stage 1 Create the Routing Rule
The first step in building an application that maps information from an IDoc is to
create a routing rule that invokes the Flow Service that will perform the mapping.
When you create the routing rule, select the B2B Service transport and specify the
Configure B2B Service parameters to identify the location of the SAP BC service
that maps the IDoc. (You will create this SAP BC service in a subsequent step.)
The following example shows the routing rule you would create to pass the IDoc to a
SAP BC service called projectA.idocs:mapOrders02.

SAP AG
Routing Rule Screen
Stage 2 Create an Empty Flow Service
After you have created the routing rule, use the following procedure to create a Flow
Service with SAP Business Connector Developer (this is the service that the Partner
Manager will invoke based on the routing rule created in the previous stage).
To create an empty Flow Service
1 Start SAP Business Connector Developer. See the SAP Business Connector
Developer’s Guide if you need procedures for this step.
2 Connect to the SAP Business Connector Server that you identified in the routing
rule you created in Stage 1 .

SAP AG
3 On the File menu, click New and create an empty Flow Service. Make sure that you
give the service the same folder and service name (projectA.idocs:mapOrders02)
specified in the routing rule you created in Stage 1 . If the necessary folders
projectA and idocs do not yet exist, you need to create them as well, before you
can create the mapOrders02 service.
Obtaining a Record Definition for Your IDoc

Regardless of the way in which you pass the IDoc to the flow, you need to create a record
describing the content and structure of the IDoc. There are three ways to create this
record:
You can generate it directly from the DDIC information of the SAP backend system. For
this choose SAP  IDoc Definition from the Developer’s menu.
You can generate it from the DTD for the IDoc.
You can generate it from a “sample” IDoc that you capture with the SAP Business
Connector Developer at design time.
The first and the third option produce the most complete Record, since they are based on
the IDoc’s complete definition, which describes all possible fields in the IDoc. We
recommend that you use these options whenever possible. Use the second option only if a
DTD is not available for the IDoc with which you are working. Because this option
derives a record from a sample document, there is no assurance that the Record will
include all possible fields. Fields that aren’t used in the sample document, won’t appear
in the record definition.
Stage 3 Create a Record Definition for your IDoc
Generating a Record Definition via direct DDIC lookup

This is the most convenient and easiest way to create an IDoc record definition.
Make sure the SAP system, from which the Business Connector will receive or to which it will
send the IDoc, is already maintained in the administration UI under Adapters  SAP  SAP
Servers. Then you can generate a record definition as follows:
1 Open the SAP Business Connector Developer.
2 From the menu choose SAP  IDoc Definition.
3 Select the SAP Server Name of the R/3 system that will send or receive the IDoc and specify
the IDoc document type (not the message type), e.g ORDERS02. The other fields can usually
be left empty. They are only needed, if you are dealing with custom modified IDoc types.
Finally press Lookup.
4 Depending on the complexity of the IDoc type, the lookup may take a couple of minutes. In the
end the Developer will display the complete IDoc tree with all segments and fields and their

SAP AG
data types. It will also display segment and field documentation as well as possible field
values, if this information is available in the backend’s DDIC.
5 Press Generate Record and Next, choose a package and a folder into which to generate the
record definition and specify a name for the new record.
6 Press Next two more times and then Finish.
7 In order to simplify consequent mappings, you may now edit the generated record and delete
segments/fields from it, which are not used in the documents that you plan to process.
Generating a Record Definition from a DTD
If you are using SAP R/3 version 4.6A or higher, you can create a DTD for an IDoc from
transaction WE60. (See your SAP user guide for procedures). If you want to generate a record
definition from a DTD that you have created, you must first create an XML file that defines a root
element and points to this DTD. (Use the XML files that SAP provides as guides.) Use this XML
file to build your record definition.
To Create a Record Definition from an IDoc DTD

2 On the File menu, select New.

SAP AG
3 On the New panel, select Record and then choose Next.

4 On the Record panel, do the following:
a) In the Folder tree, select the Folder into which you want to save the record definition.
b) In the Name field, type a name for the record using any combination of letters, numbers, and/or the
underscore character. (You might want to include the name of the IDoc in the name.)
5 Select Next
6 On the XML Format panel, select Local DTD or XML Document, and press Next.
7 From http://ifr.sap.com you can download the corresponding XML file (or
schema) respectively the DTD file (or schema) to any directory your developer
has access to. Alternatively generate a DTD in the backend using transaction
WE60 and copy the file to your local machine.
8 Choose Finish.
9 If your IDoc is earlier than Version 3 (e.g. R/3 3.1I), edit the record definition to
remove the “40” designation from the control header element. For example,
change EDI_DC40 to EDI_DC.
10 Select to save the Record.
Generating a Record Definition without a DTD

If you do not have (or cannot create) a DTD for your IDoc, you will have to generate your
record definition from a sample document that you submit to the SAP Business
Connector Developer at design time. If you have to use this option, you must obtain (or
create) a comprehensive sample document before you begin building the SAP BC service.
The sample document should contain examples of all possible fields in the IDoc. (Fields
that are not represented in the sample document, will not appear in the Record definition.)
To Create a Record Definition without a DTD

2 On the File menu, select New.
3 On the New panel, select Record and then choose Next.
4 On the Record panel, do the following:
a) In the Folder tree, select the Folder into which you want to save the record definition.
b) In the Name field, type a name for the record using any combination of letters, numbers, and/or the
underscore character. (You might want to include the name of the IDoc in the name.)
5 Press Finish.
6 Now switch to the empty Flow Service (projectA.idocs:mapOrders02) you created in
Stage 2 .

SAP AG
7 Choose on the Flow Pane toolbar, and select the pub.flow:savePipeline service. (If
this service does not appear in the list, select Browse… to find it.) This service will copy the
contents of the pipeline so that you can retrieve it in a later stage. (Later on, the savePipeline
step will be deleted from your flow again. Its purpose is simply to capture a copy of the IDoc—
it is not a permanent part of your Flow.)
Add the savePipeline

service to the flow…
…and set this variable

to assign a name to the
saved pipeline
8 Select the Pipeline tab.
9 Select the $name variable under Service In and press on the toolbar.
10 Type a name for the saved pipeline (for example, SaveIDoc) and select OK.
11 Choose to save the Flow Service.

12 Send your sample IDoc to this service as described below:
Use the SAP GUI or the utility at /SAP/Submit_ IDocXML.html to submit your
sample IDoc to the Partner Manager. Specify the sender, receiver, and
message type that you used for the routing rule that you created in Stage 1 .
Make sure that the document you submit is a comprehensive example that
contains all possible fields for that IDoc. When the Partner Manager receives
this document, it invokes the Flow Service you created above, which captures
the IDoc by making a copy of the pipeline. In the next step, you will retrieve the
saved image of the pipeline.
The pipeline image created by the savePipeline operation is stored in memory and can be recalled
by any subsequent service. However, the image is not stored on disk. If the server is restarted, it
will no longer be available. You can create a permanent copy by using savePipelineToFile
instead.
Use the following procedure to retrieve the pipeline image you created:

SAP AG
13 In SAP Business Connector Developer open the Flow projectA.idocs:mapOrders02

from the previous steps.
14 Select the Flow tab.
15 Delete the savePipeline step and then choose on the Flow Pane
toolbar and select the pub.flow:restorePipeline service. (If this service does
not appear in the list, select Browse… to locate it.) This service will retrieve the
contents of the pipeline you saved previously.
At this point, your flow

contains only the
restorePipeline service
16 Under Service In, select the $name variable under and choose on toolbar
in the Pipeline tab.
17 Specify the name of the saved pipeline and select OK.
18 As the next step of this service insert pub.web:documentToRecord (to be
found also in the WmPublic Package), if the IDoc was sent to the Business
Connector via http, or pub.sap.idoc:iDocToRecord (to be found in the SAP
Package), if the IDoc was sent to the Business Connector from an SAP system
via tRFC or from the demo page /SAP/Submit_ORDERS_IDOC.html.
19 Choose to save this Flow Service.

20 Execute this service and then select the Results tab and locate the boundNode
variable. It should contain the data of your IDoc.
Now we can continue creating our Record Definition:
21 Select the root Record defined within boundNode. In the following example, the
root Record is ORDERS02.

SAP AG
Locate the boundNode

variable…
…and select the root record

within it
22 Select EditCopy to make a copy of the root Record.

23 Now switch back to the empty record definition you created in step 4 and mark
the empty pane on the right-hand side. Select EditPaste to paste the
structure of the captured IDoc into your Record Definition.
24 Choose to save this Record Definition.
Mapping the data in an IDoc

This section describes how to build a Flow Service that maps IDoc information into
another Record structure. To accomplish this, follow the procedures in the stages below.
This mapping service can for example be used as a pre-processing Flow in a routing rule which
processes such IDocs and needs to forward a document in a different format (the format created
in the mapping).
Stage 4 Transforming the IDoc to Hierarchical Format
To extract information from an IDoc, your Flow Service must transform the IDoc into a hierarchical structure
and generate a boundNode — a record whose elements correspond to the fields in the IDoc. To do this,
either use the iDocToRecord service (if the IDoc will be received by the Business Connector via tRFC or via
http POST with Content-Type: application/x-sap.idoc) or the documentToRecord service (if the IDoc will be
received via http POST with Content-Type: text/xml).
To transform the IDoc to hierarchical format
1 Select on the Flow Pane toolbar and choose the

pub.sap.idoc:iDocToRecord service or the pub.web:documentToRecord
service. (If this service does not appear in the list, select Browse… to locate it.)
Either service transforms the IDoc into a boundNode variable, which contains the
contents of the IDoc in a format that you can map to other pipeline variables.

SAP AG
You add the

iDocToRecord service
to your flow...
…to produce a
boundNode
The picture above includes a restorePipelineFromFile operation. This is for

testing and debugging the mapping as described later in Stage 6 . In
production, your flow will not contain this flow operation.
2 Select to save this Flow Service.
Stage 5 Mapping IDoc Information to Pipeline Variables
After transforming the IDoc into a boundNode, you can map the fields of the IDoc to other variables in the
pipeline (for example, to variables in a cXML or OAG document). To do this, you must add a MAP operation
to the flow, insert record definitions for the IDoc and the target document, and then map fields in the IDoc to
the appropriate variables in the other document.
The following procedure describes how to add the MAP operation to the service and configure the MAP
operation to copy values from the IDoc to other variables in the pipeline.
To map the IDoc to variables in the pipeline
Perform the following steps to add a record describing the content and structure of
the IDoc.
1 In the SAP Business Connector Developer, select the Flow tab.
2 In the Flow Pane, select the iDocToRecord/documentToRecord operation.
3 Select the Pipeline tab and choose the boundNode variable under Pipeline Out.

SAP AG
4 Choose on the toolbar and select Record Reference.

5 In the Name field, type the fully-qualified name of the record definition, you
created in Stage 3 , or select it in the Folder tree.
6 Press OK.
7 Type a name for this Record and press ENTER. (You can give this Record any
name you like, but we suggest that you identify the IDoc in the name.)
When you finish this step, Pipeline Out should contain a record that defines the
structure of your IDoc. (Don't save the flow at this stage, because if you do, the
yet unused Record Reference will be deleted again from the service...)
Insert the record

definition in Pipeline
Out
8 In Service Out, select the boundNode variable.
9 In Pipeline Out, select the IDoc Record and press Map , or map
boundNode to the IDoc Record using ‘drag and relate’:
10 The Pipeline Editor will show a connecting line between boundNode and the IDoc
Record you created in the previous procedure.
Map the boundNode

variable to the record
definition
Now perform the following steps to define the variable(s) to which you want to map information from the IDoc.
11 Choose Map on the Flow Pane toolbar.

Make sure the MAP operation appears immediately after the
pub.sap.idoc:iDocToRecord operation. If necessary, use the arrow buttons on
the toolbar to move it to the correct position.
13 In Pipeline Out, select the bottom most variable, and then choose
from the toolbar and select the type of variable to which you want to map an
IDoc value.
14 Type the name of the variable and press ENTER.

SAP AG
15 If the variable is a Record or a Record List, repeat steps 13 and 14 to define its
member variables. Then use to indent each member variable beneath the
Record or Record List variable.
16 Repeat this set of steps for each variable to which you want to map an IDoc
value.
For additional information about creating variables, see “Adding Variables with
the Pipeline Editor” in the SAP Business Connector Developer’s Guide.
17 Use Map to map fields from the IDoc Record in Pipeline In to the
appropriate target variables in Pipeline Out. If you need additional information
about this step, see “Mapping Pipeline Variables to Service Inputs and Outputs”
and “Working with the MAP Operation” in your SAP Business Connector
Developer’s Guide.
The following example shows a variable mapped from the ORDERS02 IDoc to a
String variable in Record called PurchaseOrder.
You can find a record definition for the example purchase order shown above in
sap.demo.records:PurchaseOrder.
Stage 6 Test the Mapping Service
To test the Flow Service you created, use the SAP GUI or the
/SAP/Submit_ORDERS_IDOC.html utility to submit your sample IDoc to the Partner
Manager. Make sure to specify the sender, receiver, and message type that you used for
the routing rule that you created in Stage 1 .
Check the results of the service to ensure that the IDoc is being mapped correctly.
If you want to debug your service in the SAP Business Connector Developer, you can use
the savePipeline/savePipelineToFile and restorePipeline/restorePipelineFromFile
services to capture an IDoc submitted by the sending system. To use this technique, do the
following.
Use the following procedure to add the savePipelineToFile service to the beginning
of your Flow Service:

SAP AG
1 Open your Flow Service in the SAP Business Connector Developer.
2 Select in the Flow Pane toolbar, and select the

pub.flow:savePipelineToFile service. If this service does not appear in the list,
select Browse… to locate it.)
Make sure savePipelineToFile is the first operation in your flow. If necessary, use
the arrow buttons on the toolbar to move it to the correct position.
4 Select the fileName variable under Service In and choose on the toolbar.
5 Type a name for the saved pipeline information (for example, SaveIDoc) and
press OK.

7 Use the SAP GUI or the /SAP/Submit_ORDERS_IDOC.html utility to
submit an IDoc to your Flow Service. When the service executes, the
savePipelineToFile operation will make a copy of the pipeline (which will
include your IDoc) and save it to file.
8 Use the following procedure to delete the savePipelineToFile service and
insert the restorePipelineFromFile service.
9 Open your Flow Service in the SAP Business Connector Developer.
11 Select the pub.flow:savePipelineToFile operation and choose to delete it.
12 Choose in the Flow Pane toolbar, and select the

pub.flow:restorePipelineFromFile service. If this service does not appear in
the list, select Browse… to locate it.)
13 Use the to move the restorePipelineFromFile service to the top of the

flow.
15 Select the fileName variable under Service In and choose on the toolbar.
16 Type a name of the saved pipeline information and press OK.

18 Select the TestRun command to execute the Flow Service. When it executes,
the restorePipelineFromFile service will retrieve the copy of the pipeline containing
your IDoc, which the remainder of the flow will operate on.
When you are finished testing, use the following procedure to delete the
restorePipelineFromFile service and save the finished flow.
2 Select the pub.flow:restorePipeline operation and choose to delete it.
3 Choose to save your Flow Service.

SAP AG
Pre-Routing Mechanisms for content-based routing with IDocs
Sometimes it is necessary to do some manipulation on IDocs before processing them in

the Business Connector or before sending them to an SAP server. This is most likely done
when there are customized IDocs which need specific processing. The two most common
manipulations are ‘Content based routing’ and ‘mapping’. Both mechanisms can be
performed on IDocs routed to the Business Connector. For IDocs going to an SAP server,
only mapping manipulation applies.
‘Content-based routing’ allows you to specify routing parameters (sender, receiver and
msgType) overriding parameters in the header of the incoming IDocs. You determine
such headers from the content of the IDoc itself. E.g. if you want to provide routing
parameters like ‘vendor’ or ‘sales organization’ in a PO as information for the receiving
system (instead of just the logical system’s name).
‘Mapping’: the mechanism that adds (or removes) data segments to (from) a document. E.g. if you want
to include the parameter ‘sales organization’ in the ORDERS IDoc.
A practical example for using the pre-routing mechanism features is if you have a special
Orders IDoc which contains its receiver and sender information in specific fields in the
IDoc itself. Further, it contains extra fields that you want removed, or added, before you
process the IDoc as an ORDER02 IDoc.
In order to do content-based routing, you need to develop Flow or Java Service meeting
certain requirements and then publish that service on the BC using a registration
mechanism. The registration mechanism assures that existing content-based routing
settings are not overridden when upgrading the BC.
You can register one special pre-routing service per message type. Also, a standard
processing service can be established, which will be executed for all message types and
provides default routing information.
You can register both inbound and outbound manipulation services. The inbound services
are executed for inbound IDocs (sent to the Business Connector) using
pub.sap.transport.ALE:InboundProcess.
The outbound services are executed before an IDoc is sent to an SAP system by
pub.sap.transport.ALE:OutboundProcess.
There are two services available, with which routing services can be registered and
unregistered:

SAP AG
• pub.sap.idoc.routing:registerService: This service registers a given service with the routing

manager. The best way to use it is to invoke it in a replication or startup service. It has the
following signature:
Input Description
msgType The message type of the IDoc for which you want to register a content-based
routing or mapping. If the special value $default is used, a “global” service
(invoked for all message types) will be registered.
service The complete namespace reference of the service to register (format:

folder.subfolder:servicename). This service needs to be implemented by you.
inbound Flag that indicates whether to register an inbound (default) or an outbound

service. Set to true or false.
Output Description
activated Flag that indicates whether the service could be activated as routing service.
Returns true or false.
activeService Only present if activated==false. In this case it contains the service that is
currently active, or $none if all registered services are deactivated.
• pub.sap.idoc.routing:unregisterService: This service unregisters a given service from the routing

manager. It has the following signature:
Input Description
msgType The message type of the IDoc for which you want to unregister a content-
based routing or mapping. If the special value $default is used, a standard
service will be unregistered.
service The fully specified service to unregister.
inbound Flag that indicates whether to unregister an inbound (default) or an outbound

service.
Output Description
wasActive Flag that indicates whether the unregistered service was the active routing
service.
The best place to invoke those services for your routing service is within a replication
service or a startup service for a package. Which of these services you choose, depends
on your own needs. Note, that also the default (global) routing service can be
manipulated by using the special message type $default.
A routing service has to use the following specifications for proper behaviour:

SAP AG
Specification Description
pub.sap.idoc.routing:inbound Specification that should be used for services

which provide an inbound content-based
routing/mapping.
pub.sap.idoc.routing:inboundDefault Specification that should be used for services

which provide a default inbound
routing/mapping
pub.sap.idoc.routing:outbound Specification that should be used for services

which provide an outbound content-based
mapping.
pub.sap.idoc.routing:outboundDefault Specification that should be used for services

which provide a default outbound mapping.
Once you registered your routing services you can associate them with message types via
the Administrator UI ( SAP -> Routing ):
Important: in the SAP Routing screen of the Administrator UI there are two sections to
select services: a message type independent section (default handling section) and a
message type dependent section.
A default handling service (inbound or outbound) is executed for all message types. If
there are services selected in the message type dependent section, they will be
executed for the corresponding message type in addition to the default service.
If the special value $none is selected, all registered services are set to inactive.
Note: the services for content-based routing have to be registered by you before they
can be selected via the Administrator UI.
Important: when implementing your own default inbound routing service, the
parameters ‘sender’, ‘receiver’ and ‘msgType’ have to be set by that service. These

SAP AG
parameters are part of the specification. If not, you will get an error message at runtime.
Note: the setting of the global default services works the same way as the setting of
regular message type specific services. You need to register a service before you can
select it. If no service has yet been registered with '$default' as message type, then the
drop-down box for selecting one will not be present. This is the case in a freshly
installed Business Connector. The '$none' choice is only there, if one or more services
are registered.
The settings in the image above indicate that for all incoming IDocs with an ORDERS
message type, the sap.idoc.mappings:orders service will be executed. The service may alter
the IDoc itself as well as the routing parameters for the IDoc. For IDocs going to SAP
with ORDRSP message type, the sap.idoc.mappings:ordrsp service will be executed. This
service can alter the IDoc by adding or removing fields (but can no longer influence the
routing).
Using the ALE Monitoring Features via the SAP BC
Introduction
When an IDoc is sent from an SAP System to the Business Connector, the status of the
IDoc (as displayed in transaction WE02) will always be "03, Data passed to port OK"
(i.e. passed to the tRFC queue of the SAP system). However, this status doesn’t provide
any information regarding whether the IDoc could be processed successfully by the
Business Connector, and who the final recipient is. To get this kind of information, the
Business Connector offers three options: IDoc Trace, ALEAUD IDoc and SYSTAT01
IDoc.
The IDoc Trace feature should be used if you sporadically want to look up the status of
certain IDocs. The lookup is done manually and only for a specific selection of IDocs. If
you want automatic status update, you should use one of the other two options described
below.
Status update via ALEAUD IDoc can be used if the final recipient is again another SAP
System. The most common case will be the connection of two SAP Systems via the
Internet like this:
SAP Server (sender)  BC 1 Internet (http) BC 2  SAP Server (receiver).
In all other cases status update via SYSTAT01 IDoc should be used. SAP Business
Connector acts here like an EDI Subsystem and returns status information and
information about the final receiver (receiving email address, Web Server URL, FTP
Server, third party system, etc.) to the sender.
These three options are now described in detail:

SAP AG
IDoc Trace
Overview
The ALE Monitor allows you to make inquiries about the processing status of an IDoc in
the receiving system actively from within the sending system. In R/3 Systems of release
below 4.6C this can be done with the transaction BDM2 (Cross System IDoc Reporting)
and from release 4.6C on with transaction BD87 (Status Monitor for ALE Messages). As
inputs you can specify certain selection criteria, like Document Number, Message Type,
LS of receiver and date ranges, and the system then makes a synchronous RFC call
(IDOC_DATE_TIME_GET) to the LS that received the IDocs, with a list of DOCNUMs
corresponding to the selected IDocs. (From transaction BD87 you have to hit the toolbar
button “Trace IDocs” after the selection of the IDocs.) This function call returns for each
IDoc the DOCNUM, under which it was saved in the receiving system, the receiving
time and the current processing status in the receiving system.
Prerequisites
• The IDoc Trace functionality only works for IDocs exchanged between partners of
Partner Type LS (Logical System).
• In order to be able to make this synchronous RFC, the partner profile of the LS, which
represents the Business Connector, must contain an outbound parameter with message
type SYNCH.
• Also, the Function Call to an LS of type “tRFC Port”, like the Business Connector, is
executed only if the SAP system is of release 4.6D or higher. For older releases you
have to apply the following hot packages:
R/3 Release Hot Package
SAPKH31I67
3.1I
SAPKH40B56
4.0B
4.5B SAPKH45B35
4.6B
SAPKB46B22 and SAPKH46B22
4.6C SAPKB46C11 and SAPKH46C11
Prepare the Business Connector for IDoc Trace

To set up the Business Connector for IDoc tracing, proceed along the following steps:
1. Shut down the Business Connector and add the following line to the file
...\Server\config\server.cnf:
watt.sap.monitorIDocs=true
2. For each SAP Server from which you want to receive and trace IDocs, create
a Function Module Inbound Map for IDOC_DATE_TIME_GET and in it
enter under “Outbound Handling”:
Folder: pub.sap.monitor.idoc
Service/Flow: idocTrace
3. All remote Business Connectors, to which IDocs are passed on via a remote
invoke of pub.sap.transport.ALE:InboundProcess (or
wm.PartnerMgr.gateway.transport.ALE:InboundProcess on older BC releases),
should also support IDoc Tracing.

SAP AG
Status Update via ALEAUD IDoc
Preparation
If the final receiver is an SAP System, the IDoc ALEAUD can be used to report status
information from the receiver back to the sender. To setup this scenario, the following
settings have to be created in the distribution models of the participating Systems:
(MATMAS is used in this example. Substitute with the IDoc type(s) used in your
scenario.)
• Sending System: For the LS that represents the receiver, set up a partner profile,
which has MATMAS as an outbound parameter and ALEAUD with process code
AUD1 as an inbound parameter.
• Receiving System: For the LS that represents the sender, set up a partner profile with
an outbound parameter ALEAUD and an inbound parameter MATMAS.
Also in the distribution model the following model view has to be created:
Sender: T90CLNT090 (or LS, which received the IDoc, if different)
Receiver: LS of sender
Message type: ALEAUD
Here add a Filter with value “MATMAS”.
Next you have to schedule a job, which executes a variant of the report RBDSTATE. The
variant has to include the LS of the sender as selection parameter. This should send out an
ALEAUD IDoc to the Business Connector.
Further Setup in the Business Connector

After all this has been set up, the ALEAUD IDoc can be routed as usual like a “normal”
IDoc. Here –and in all other cases, where sender/receiver information in the IDoc
Control Header has been changed by a mapping-- only one thing has to be taken into
account: the last Business Connector, who pushes the ALEAUD into the original sending
system, has to set the values of EDI_DC40-SNDPRN and EDI_DC40-RCVPRN to the
inverse of their original values.
For example: If your original IDoc went out with a header segment such as:
Sender Receiver
LS T90CLNT090 LS XYZCLNT123
Then the ALEAUD has to be pushed in with this header:
EDI_DC40-SNDPRN = XYZCLNT123
EDI_DC40-RCVPRN = T90CLNT090
This can be achieved by adding the service sap.monitor.idoc.mappings:setReceiverToLS as
preprocessing service to the Routing Rule and hard coding the corresponding values
there.

SAP AG
Status Update via SYSTAT01 IDoc
Overview
In this case the Business Connector can be considered as a kind of EDI Subsystem. If the
SYSTAT01 feature is enabled, it automatically sends a customary EDI Subsystem Status
and some additional information for each IDoc it received back to the original sender.
You can decide for each Routing Rule, whether SYSTAT01 information should be
reported to the sender or not. The following information is then reported in addition to
the status:
 Program that set the status (SAP Business Connector)

 Routing Rule, which processed the IDoc
 The key (TID) under which the IDoc can be found in the Business Connector
 Date and time of status change
 In case of an error status: explicit error message
 In case of a success status: explicit information about the final receiver in the
following form:
 ALE Transport: IDoc(s) submitted to <SAPSystem> with
tid: <TID>
 XML Transport: Posted Document to <URL>
 Email Transport: Sent Msg to <emailAddress>
 FTP Transport: Sent Msg to <hostname>:<port>
 B2B Transport: Sent Msg to service
<folderPath>:<serviceName> on Server <alias>
The Business Connector sends the following status:

 If everything went ok the first time: "06 Translation OK" and "12 Dispatch OK"
 If an error has occurred the first time: "11 Error during dispatch"
 If everything went ok at a later retrial: "13 Retransmission OK"
 If there was still an error at a later retrial: "23 Error during retransmission"
 If no information on the IDoc could be determined: "04 Error within control
information of EDI subsystem"
Setup the participating SAP Systems

In each SAP System that is to receive SYSTAT01 IDocs from the Business Connector,
you need to configure the following settings:
In SAP Systems of Release 3.1H - 3.1I you need to perform the following additional
step, before continuing with the general setup:
Go to transaction WE42 (Process codes, inbound) and open the two tree branches
"Inbound with ALE service  Processing by task" and "Inbound without ALE service
 Processing by task". Here you need to reassign the process code "STA1" from
"without ALE service" to "with ALE service", if this has not been done yet. For this,
proceed as follows (it is a bit "non-intuitive"...):
 Mark the node "Inbound without ALE service  Processing by task  STA1 Status
record from IDoc" with the cursor and then press the "Reassign" button (F6).
 Confirm the popup

SAP AG
 Double click on the node "Inbound with ALE service  Processing by task"
 In the following screen press the "Save" button (F11).
General setup:
1. In transaction SALE (Distribution (ALE)) go to "Basic configuration  Set up logical
system  Maintain logical systems" and add a new logical system for the Business
Connector, if you don't have one yet. If you name it "BUSCON", the Business
Connector will recognize it automatically; else you will have to make the name known
to the Business Connector as described later.
2. In transaction WE20 (Partner Profiles) create a partner profile with "Partn.number" =
the name you chose in step 1 (e.g. "BUSCON") and "Partn.type" = "LS". After you
saved it, add an Inbound Parameter to it as follows:
"Message type" = "STATUS"
"Process code" = "STA1"
Prepare the Business Connector for Automatic SYSTAT01 IDoc

In the Business Connector you have to setup these elements to enable automatic status
update via SYSTAT01:
1. If you chose a different name from "BUSCON" for the logical system above,
shutdown the Business Connector and add the following parameter to
...\Server\config\server.cnf:
watt.sap.systat01.partnerNumber=<NameOfLogicalSystem>.
Start the BC again.
With "BUSCON" you can omit this step.
2. Go to Adapters  Routing  Routing Rules, and add the following Service in the
field "Pre-Processing Service" for each Routing Rule, for which you want to enable
SYSTAT01 Status update (or include it as the first step of the Pre-Processing Service,
if you have already your own Pre-Processing Service defined):
pub.sap.monitor.systat01:enable
All IDocs, which come in via this Routing Rule, are now marked for automatic status
update.
3. Go to "Server  Scheduler  Create a scheduled task" and schedule the Service
pub.sap.monitor.systat01:report.
4. Here you specify time intervals for the Service. You should try to schedule it for times
when you know that there is little load on the system. On the other hand, in order to
prevent the resulting SYSTAT01 IDocs from getting too big, you should schedule it
often enough, so that at most around 2000 IDocs have been received by the Business
Connector since the last run of the report Service. Normally it should be ok to
schedule it once per hour.
This Service collects all the necessary information and error/success messages for
those IDocs, which the Routing Rules chosen in step 2 have processed since the last
run. For each SAP System that has sent any such IDocs to the Business Connector, it
creates and submits one SYSTAT01 IDoc containing all this information.

SAP AG
Improving the Performance of the Partner Manager
The Partner Manager offers four switches to improve throughput and performance. These
switches control the way how transactions and messages are persisted. In order to be
effective, these switches have to be added as statements to the server.cnf configuration
file. Please read the Appendix B ‘Server Configuration’ on how to set and modify the
statements.

SAP AG Coding Client Applications and Services
Chapter 8: Coding Client Applications and Services
Overview ............................................................................... 8-2

Invoking RFCs from SAP Business Connector Server ............. 8-2
Receiving IDocs from an SAP System .................................... 8-4
Constructing an IDoc with the SAP Java ................................ 8-6
Sending IDocs to an SAP System .......................................... 8-8

SAP AG
Overview
The SAP Business Connector Server has several APIs that you can use in your client
applications and services.
This chapter shows how to use the built-in services API to invoke SAP RFCs, send IDocs
to an SAP server, and to receive an IDoc from an SAP server. For descriptions of the
available built-in services, refer to SAP Business Connector API on page D-1.
This chapter also shows how to use the IDoc Java API to construct an IDoc. For historical
reasons the Business Connector 4.8 contains five different APIs for creating and
traversing IDocs:
1 The classes IDOC, IDOCControl and IDOCSegment in the package
com.wm.pkg.sap.idoc
This is a very basic implementation introduced with SAP BC 3.0.1 (1999). It does not
support IDoc Packets and complex tree operations and should no longer be used. Only
included for backward compatibility reasons.
2 The IDoc base library 1.0 (the class com.sap.mw.idoc.IDoc and its nested classes)
This library was introduced in SAP BC 4.7 and should no longer be used. Only
3 The Business Connector IDoc library 1.0 (the classes BCDocumentList,
BCDocument, BCSegment, BCRecord and JCoBCDocumentList in the package
com.wm.pkg.sap.idoc)
This library was introduced in SAP BC 4.7 and should no longer be used. Only
4 The IDoc base library 3.x (the package com.sap.conn.idoc)
Introduced with SAP BC 4.8.
Use this API, if you want to write mappings/services, which will be able to process
both kinds of IDocs: those that came in via an RFC call from an SAP system (and
consequently contain correct metadata information from an R/3 DDIC) and those that
came in via XML document (and consequently don’t have a reference to a metadata
repository yet).
JavaDoc for these classes is available at
<sapbc>\Server\packages\SAP\pub\doc\idoc30\index.html .
5 The Business Connector IDoc library 3.x (the classes BCIDocDocumentList,
BCIDocDocument, BCIDocSegment, BCIDocRecord and
JCoBCIDocDocumentList in the package com.wm.pkg.sap.idoc)
Introduced with SAP BC 4.8.
Use the class JCoBCIDocDocumentList, if you know that the IDocs, which your code
will be processing, came in via RFC, or if you are manually constructing an IDoc at a
point, where it is already clear, into which SAP system the IDoc will be sent. (The
DDIC of the SAP system given in the constructor will then be used for metadata
information.) Continue with the classes from com.sap.conn.idoc.
Use the class BCIDocDocumentList, if you know that the IDocs, which your code will
be processing, came in as an XML document, or if you are manually constructing an

SAP AG
IDoc at a point, where no information about a possible receiving SAP system is yet
known. Cast the return values of the API to the classes BCIDocDocument and
BCIDocSegment as appropriate. When using this API, no automatic syntax checks for
IDoc fields and segments will be performed.
JavaDoc for these classes is available at
<sapbc>\Server\packages\SAP\pub\doc\api\index.html
For easy ways and an automatic tool to migrate BC 4.7 Java mappings (IDoc library
version 1.0) to the IDoc library 3.x, see the BC 4.8 Upgrade Guide.
Invoking RFCs from SAP Business Connector Server

You can use built-in services that are shipped with the SAP Business Connector Server to
invoke an RFC on an SAP server.
Calling SAP Services from Java Services

This section shows an example of how to invoke an RFC from a SAP BC Java service.
The sample Java TestBAPI.java that is shown below, logs on to a SAP server and invokes
a BAPI.
For more information about developing services, see the SAP Business Connector
Developer’s Guide and the online API documentation installed with the SAP Business
Connector Server (<sapbc>\server\doc\api\Java\index.html).
To call a SAP service from Java
1. Start the SAP Business Connector Developer if it is not already running.

2. Create a Java service named TestBapi and enter the following source:
IDataCursor idc=pipeline.getCursor();
IDataUtil.put(idc, "serverName", "HS1");
IDataUtil.put(idc, "COMPANYID", "000001");
IDataUtil.put(idc, "$rfcname", "BAPI_COMPANY_GETDETAIL");
try
{
Service.doInvoke("pub.sap.client", "invoke",
pipeline);
}
catch (Exception e)
{
throw new ServiceException(e);
}
finally
{
idc.destroy();
}
This service will invoke BAPI_COMPANY_GETDETAIL with a company ID of
000001 and return the results. The logon to the SAP System is done automatically
using the connection information for the SAP Server HS1.
Change the SAP Server alias to your own alias if necessary.

SAP AG
Receiving IDocs from an SAP System

To receive an IDoc from an SAP system and pass it to a SAP BC service, route the IDoc
through the Partner Manager. To route an IDoc through the Partner Manager to a SAP BC
service, you need to set up a routing rule for the IDoc. For instructions on establishing
routing rules, refer to “Establishing Routing Rules” on page 5-8. When choosing the
transport for the routing rule, select the B2B service transport. After selecting B2B
service, you need to supply information that indicates to which SAP BC service you want
the SAP Business Connector to pass the IDoc.
With Release 4.8 SAP BC uses the SAP Java IDoc Library version 3.0 to process
IDocs. For easy ways and an automatic tool to migrate BC 4.7 Java mappings
(IDoc library version 1.0) to the IDoc library 3.x, see the BC 4.8 Upgrade Guide.
Accessing and Modifying Fields in IDocs

The following code sample shows how to use the SAP Java IDoc Library 3.x to convert
an IDoc to a structured document with direct access to each field. This allows you to
modify an IDoc’s contents on the fly. For example, if you want to customize incoming
IDocs based on local data format, you can do so. Note that the following code uses the
base API, so makes no assumptions as to whether the IDoc came in via RFC or XML.
IDocDocumentList iDocList;
if (idc.first("iDocList"))
iDocList = (IDocDocumentList)idc.getValue();
else throw new ServiceException("Missing input: iDocList");
IDocDocument[] array = iDocList.toArray();

IDocSegment root, segment;
String action = null;
try{
for (int i=0; i<array.length; i++){
root = array[i].getRootSegment();
segment = root.getNext("E1EDK01");
if (segment != null) action =
segment.getString("ACTION");
else action = null;
if ("000".equals(action)){
//...
}
else if ("001".equals(action)){
//...
}
}
}
catch (IDocFieldNotFoundException e){
throw new ServiceException(e);
}

SAP AG
Include the line:

com.sap.conn.idoc.*
under Shared  Imports.
For more information about using the SAP Java IDoc Library, refer to “Constructing an
IDoc with the SAP Java IDoc Library” on page 8-6.
Converting an IDoc to XML

The following code sample shows how to convert an IDoc to XML.
IDataCursor c = pipeline.getCursor();
Service.doInvoke("pub.sap.idoc", "encode", pipeline);
String xmlString = IDataUtil.getString(c, "xmlData");
c.destroy();
See description of service pub.sap.idoc.encode for details about the expected input
parameters.
Traversing all segments and attributes of an IDoc
The following code sample shows how to traverse all segments and attributes of a
received IDoc. It also demonstrates how to use segment meta data information.
IDocDocumentList iDocList;
if (idc.first("iDocList")) {
iDocList = (IDocDocumentList)idc.getValue();
}
else {
throw new ServiceException("Missing input: iDocList");
}
IDocDocument[] array = iDocList.toArray();
IDocSegment root, segment;
for (int i=0; i<array.length; i++) { // loop all idocs

root = array[i].getRootSegment();
// traversing all segments
segment = root.getNext();
while (segment != null) {
// do something with the segment meta data
IDocSegmentMetaData meta = segment.getSegmentMetaData();
System.out.println("Segment Name:" + meta.getName());
System.out.println("Min Occur:" +
meta.getMinOccurrence());
System.out.println("Max Occur:" +
meta.getMaxOccurrence());

SAP AG
// loop over all attributes

for (int j=0; j < segment.getNumFields(); j++) {
System.out.println(segment.getName(j) + ":" +
segment.getString(j));
}
segment = segment.getNext();
}
}
Include the line:

com.sap.conn.idoc.*
under Shared  Imports.
Constructing an IDoc with the SAP Java IDoc Library

The following sample shows how to construct a new MATMAS IDoc.
Remember to include com.wm.pkg.sap.idoc.* and com.sap.conn.idoc.* under
Shared  Imports.
The first three lines are generated by the SAP Business Connector Developer.
public final static void createIDoc (IData pipeline)

throws ServiceException
{
//create a new and empty MATMAS02 document
BCIDocDocumentList iDocList = new BCIDocDocumentList();
BCIDocDocument doc=
(BCIDocDocument)iDocList.addDocument("MATMAS02");
//set the appropriate control header data

doc.setIDocNumber("0000047112211178");
doc.setClient("000");
doc.setDirection("1");
doc.setRecipientPartnerType("LS");
doc.setMessageType("MATMAS");
doc.setRecipientPartnerType("LS");
doc.setRecipientPartnerNumber("TSTCLNT000");
doc.setSenderPort("SAPBCIDOC");
doc.setSenderPartnerType("LS");
doc.setSenderPartnerNumber("SBCCLNT000");
doc.setCreationDate("20030511");
doc.setCreationTime("103051");
doc.setSerialization("20030511103051");
//get the root segment from the document

//The root segment does not contain any fields or data. It is only
//used as the standard parent segment and won't be transmitted when
//the document is sent to an SAP system.
BCIDocSegment segment = (BCIDocSegment)doc.getRootSegment();

SAP AG
//create and add a new and empty child segment of type E1MARAM
//and fill the segment data
segment = (BCIDocSegment)segment.addChild("E1MARAM");
segment.setValue("MSGFN", "005");
segment.setValue("MATNR", "BOXCOOKIES");
segment.setValue("ERSDA", "20030303");
segment.setValue("ERNAM", "TOPSI");
segment.setValue("PSTAT", "KBG");
segment.setValue("MTART", "FERT");
segment.setValue("MBRSH", "L");
segment.setValue("MATKL", "G1113");
segment.setValue("MEINS", "PCE");
segment.setValue("BLANZ", "000");
segment.setValue("BRGEW", "0.550");
segment.setValue("NTGEW", "0.000");
segment.setValue("GEWEI", "KGM");
segment.setValue("VPSTA", "KBG");
//create and add a new and empty child segment of type E1MAKTM
segment = (BCIDocSegment)segment.addChild("E1MAKTM");
segment.setValue("SPRAS", "D");
segment.setValue("MAKTX", "Schachtel mit Keksen");
segment.setValue("SPRAS_ISO", "DE");
//create and add a new and empty sibling segment of type E1MAKTM
//(same type) and fill the segment data
segment = (BCIDocSegment)segment.addSibling();
segment.setValue("SPRAS", "E");
segment.setValue("MAKTX", "Box of cookies");
segment.setValue("SPRAS_ISO", "EN");
//create and add a new and empty sibling segment of type E1MARCM
segment = (BCIDocSegment)segment.addSibling("E1MARCM");
segment.setValue("WERKS", "0001");
segment.setValue("PSTAT", "BG");
segment.setValue("PLIFZ", "0");
segment.setValue("WEBAZ", "0");
segment.setValue("PERKZ", "M");
segment.setValue("AUSSS", "0.00");
segment.setValue("BESKZ", "E");
segment.setValue("AUTRU", "X");
//create and add a new and empty sibling segment of type E1MBEWM
segment = (BCIDocSegment)segment.addSibling("E1MBEWM");
segment.setValue("BWKEY", "0001");
segment.setValue("VPRSV", "S");
segment.setValue("VERPR", "0.00");
segment.setValue("STPRS", "15.50");

SAP AG
segment.setValue("PEINH", "1");
segment.setValue("BKLAS", "7920");
segment.setValue("VJVPR", "S");
segment.setValue("VJVER", "0.00");
segment.setValue("VJSTP", "15.50");
segment.setValue("LFGJA", "2002");
segment.setValue("LFMON", "08");
segment.setValue("PSTAT", "BG");
segment.setValue("KALN1", "000100126602");
segment.setValue("KALNR", "000100126603");
segment.setValue("EKALR", "X");
segment.setValue("VPLPR", "0.00");
segment.setValue("VJBKL", "7920");
segment.setValue("VJPEI", "1");
segment.setValue("BWPEI", "0");
IDataUtil.put(idc, "iDocList", iDocList);
idc.destroy();
}
Sending IDocs to an SAP System

The basic steps to send an outbound IDoc from either a client or a service are:
1. Create a transaction ID by invoking the pub.sap.client:createTID service.
2. Send the IDoc to the SAP server by invoking the pub.sap.client:sendIDoc service,
passing in the SAP Java IDoc Library object (iDocList, for example as constructed
above).
If an error occurs, repeat the pub.sap.client:sendIDoc service invocation with the same
transaction ID. The SAP System guarantees that the transaction will execute only
once.
3. After pub.sap.client:sendIDoc returns successfully, invoke pub.sap.client:confirmTID.
Transaction Features for HTTP and SAP-XML
When executing HTTP Posts using IDoc-XML and XRFC with transactions, you should
make sure that your client correctly handles such calls. It should have transaction
management that supports at least the following features:
 Transaction ID generation.
 Resending documents with same transaction ID in error cases.
 After a successful execution of a transaction (and the concluding
confirmTID), a document must not be sent again.

SAP AG
To transfer the transaction ID to the BC, you add an extra header to the HTTP POST,
x-tid, which contains the transaction ID.
Example for HTTP POST of an IDoc:
POST /invoke/pub.sap.transport.ALE/InboundProcess HTTP/1.0

x-tid: 9B38FA81133A38B518A10036
Content-type: application/x-sap.idoc
Content-Length: 4242
<MATMAS02>
<IDOC BEGIN="1">
<EDI_DC SEGMENT="1">
<TABNAM>EDI_DC</TABNAM>
<MANDT>000</MANDT>
<DOCNUM>0000047112211178</DOCNUM>
<DOCREL/>
<STATUS/>
<DOCTYP>MATMAS02</DOCTYP>
<DIRECT>1</DIRECT>
...
</MATMAS02>
For XRFC documents, you can alternatively put the transaction ID in the header of the
document:
<?xml version="1.0"?>
<sap:Envelope xmlns:sap="urn:sap-com:document:sap" version="1.0">

<sap:Header xmlns:rfcprop="urn:sap-com:document:sap:rfc:properties">
<rfcprop:Transaction>0A1104DC080C3C60F9E106A1</rfcprop:Transaction>
</sap:Header>
<sap:Body>
<rfc:SBC_TEST_SAVE xmlns:rfc="urn:sap-com:document:sap:rfc:functions">
<INPUT>Have fun!</INPUT>
</rfc:SBC_TEST_SAVE>

SAP AG
</sap:Body>
</sap:Envelope>

SAP AG
Chapter 9: Security
Product Availability ................................................................ 9-2
SAP BC Configuration ........................................................... 9-2
Initializing the Security Settings in the SAP BC ....................... 9-3
User Authentication between SAP BC and SAP System ........ 9-3
Authorization Configuration in the SAP Environment ............. 9-10
Installing SAP BC according to your Security Policy .............. 9-10
References .......................................................................... 9-11

SAP AG
Product Availability
As of Business Connector 4.8.1 there is only a strongly encrypted version. The version
with weak encryption (56 bit) is discontinued.
SAP BC Configuration
Please refer to the SAP BC Certification Toolkit User's Guide, the SAP BC Security Best
Practices Document and the SAP BC Administration Guide for information on how to
configure your server securely.
Specify settings before starting the listener

Both the certificates and private keys are stored in the file system. Therefore, restrict access to
these directories using operating system tools to ensure that the keys cannot fall into the wrong
hands, or that non-trusted certificates can be stored.
SAP Business Connector Developer

You can also use SSL to secure the connection between the SAP BC Developer and the
SAP BC. This requires the following:
• The installed version of the Developer must support SSL.
• The SAP BC must be set up as an HTTPS server as described in the SAPBC
Administration Guide chapter 7.
• To open a connection to the server, the option “uses secure connection” and the
corresponding SSL port in the SAP BC must be selected.
• According to the network architecture, you must determine whether a connection to
the SAP BC is possible, and not separated by a firewall, for instance.
• Username and password must be entered for authentication. Authentication is also
possible using a client certificate. For details, contact SAP.
Java Client Code

SSL can also be used when calling a service from Java client code. For this, the
Developer must change the source code as follows:
• A configuration file is not used on the client side and therefore all properties must be set in the
static block:
static {
// for trusted certificates
com.wm.util.Config.setProperty(„watt.security.CADir“, „cadir“);
…
}
• A change in the context is required:
context.setSecure(true);

SAP AG
Initializing the Security Settings in the SAP BC

To initialize the security settings, please refer to the SAP BC Certification Toolkit Guide, which
can be downloaded from http://service.sap.com/sbc-download  Documentation.
User Authentication between SAP BC and an SAP System
Authentication through Username and Password

When logging on through an HTTP or FTP client, standard user/password authentication is used,
the user is mapped to a SAP BC session and eventually a service calling an SAP System will be
executed. This service will use the logon parameters associated with an SAP System alias which
will most likely not reflect the identity of the original HTTP client. The SAP user is much more a
pool user shared among several physical users, which allows optimal performance.
Authentication through X.509 Certificate

Another method for user authentication in the SAP BC is through client authentication as a part of
the SSL protocol. This requires that the corresponding HTTPS listener (port) requests a Client
Certificate and that the client sends a trusted certificate that is mapped to an existing SAP BC
user. A certificate is considered “trusted”, if it has been issued by a CA (Certificate Authority)
and is listed in a local CA Certificate Directory.
It is then possible to logon to the SAP system by means of this X.509 certificate. You need to
install and configure a library supporting SAP’s Secure Network Communication (SNC)
Standard. SNC works on top of the RFC protocol. The following instructions describe the setup of
this authentication method.

SAP AG
Important: For the authentication via certificates against an SAP system it is

required to enable SNC connections on your SAP BC as well as on the SAP
application server. These settings are listed in the section Defining SAP servers
(security options) on page 3-4. For detailed information on the SAP application
server and SNC client settings for SNC see the corresponding SAP
documentation.
To define an HTTPS port that requests client certificates
1 Choose: Ports from the Security section of the initial screen

2 Click on the HTTPS Port you want to edit
3 Click on Edit HTTPS Port Configuration
4 Enter the option ‘Request Client Certificates’ in the field ‘Client Authentication’

SAP AG
For more information on ports see the SAP BC Administration Guide, Chapter 6 (Configuring
Ports).
If you want to log on to an SAP system via SAP BC using any SAP user and a certificate, you can do so by
providing a trusted certificate for the SAP BC. In a first step you have to request a signed certificate from a CA.
You can do so using the SAP BC Certificate Toolkit (free download: http://service.sap.com/sbc-download. For
more information on how to request a certificate from a CA see the SAP BC Certificate Toolkit Guide).
Having received the CA’s certificate (root certificate), you can import the corresponding (personalized) client
certificates for each user from a local directory to the SAP BC.
To import a client certificate from a local directory to the SAP BC
1 Choose Certificates from the Security Section of the initial screen

2 Click on the link Client Certificates
3 Enter the Certificate path
4 Click on the Import Certificate Button
For validation purposes you also have to enter the path to the CA Certificate directory.
The CA Certificate directory specifies the name of your local directory containing the
root certificates of CAs that this server trusts. You may specify the directory using an
absolute path or one that is relative to the <sapbc>\server directory.

SAP AG
To specify the CA Certificate directory
1 Click on Certificates in the Security section of the initial screen.

2 Click on the link Edit Certificate settings.
3 Enter the path for the CA Certificate directory in the section Trusted Certificates.
Attention: If you leave the Trusted Certificates setting blank, the server will accept (trust) any
certificate it receives during an outbound request (a certificate the BC server receives from a
server that it submits a request to). However, the server never implicitly trusts a certificate for the
purpose of authenticating an inbound request or validating an S/MIME signature. When you use
either of these features, you must specify a Trusted Certificates directory, and that directory must
contain the certificates of the CAs that your BC server trusts.
When a user logs on (e.g. from a Web client) using a certificate, the SAP BC verifies the root certificate in the
CA Certificate directory and then passes the client certificate including the username to the SAP system
automatically. However, you have to make sure that this user can access the services he wants to execute in the
SAP BC. That’s why you have to map the client certificate to the corresponding SAP BC user or alternatively to
a (standard) SAP BC user, depending on the authorizations required. If you want to execute a protected service
within the SAP BC, the mapped user must be allowed in the corresponding ACLs (access control lists). For more
information on ACLs see SAP BC Administration Guide, Chapter 8 (Managing Server Security).
Example: You want to execute a service on the SAP BC that retrieves sales order data
from an SAP system. This service is protected by an ACL. The SAP BC user ‘Sales’ is
registered in this ACL and allowed to execute the service. If you map the certificate to
the user ‘Sales’, your SAP BC user can execute this service. In addition, the SAP (R/3)
user, to which the certificate gets mapped inside the R/3 system, must have the
necessary authorization to execute the function modules of the corresponding sales
order function group.
To map a client certificate to a SAP BC user
1 Choose: Certificates from the Security section on the initial screen.

2 Click on the link Client certificates.
3 In the section Current Certificates click on the certificate’s name you want to
edit.
4 Click on the link Change user mapping.
5 Select a SAP BC user that is registered in the required ACLs.
To restrict the rights of the SAP logon users you should create specific user accounts in
the SAP system with the minimum necessary set of authorizations. If for instance SAP

SAP AG
BC is used as a pure RFC-Server, it will perform only very few function callbacks into
the calling SAP System. These callbacks are needed to determine the function module
interface specifications from the SAP system’s DDIC. To allow for this it is sufficient to
use an SAP logon user with the authorization for the following SAP standard function
groups:
RFC1, SDIF, SG00, SRFC.
See SAP Note 460089 for more details.
If this user shall be used to call other application interfaces as well, you need to add the
respective function groups to the authorization list. Add this authorization to the
standard authorization object 'S_RFC' and create an authorization profile which only
contains this authorization. When creating the SAP user, you can then assign this profile
to it. For more details on authorization for SAP users please refer to the SAP
documentation. Again, see SAP Note 460089 for more details.
Authentication when SAP BC acts as RFC-Server
RFC Listener / RFC Destination of type TCP/IP

If the SAP Business Connector is called from an SAP System, the call is always trusted.
Therefore, only the username from the SAP System is used for the logon. This user is the
user who triggered the synchronous or asynchronous call. If a user wants to execute a
service protected by an ACL (access control list) this user must be entered in the
corresponding ACL that allows access to this service.

SAP AG
If the SAP system user is not defined in the SAP BC’s user management, the user
SAPUser (Password: 22101999) is used as the default user for incoming RFC calls. I.e.,
if the SAP BC is called by an SAP user that does not exist within SAP BC, the system
switches automatically to the user SAPUser as default user.
The user SAPUser is part of the User Group SAPUsers and therefore also figures in the
ACL SAPUsers that protects all Inbound Maps and Inbound Processes of SAP BC
transports.
The user SAPUser, as well as the corresponding User Group and ACL are created
automatically when you are starting the SAP BC server for the first time.
If an SAP user has been created in SAP BC, in order to execute all Inbound Maps within
SAP BC, you have to assign this user at least to the User Group SAPUsers.
If you want to avoid that an SAP user which has not been created within SAP BC, can
use the whole authorization range of the SAPUser, you should assign SAPUser only to
those User Group(s) or ACL(s), which it absolutely needs.
The usernames in SAP BC are case sensitive!
RFC Listener / RFC Destination of type WebSocket

When using the WebSocket protocol for communication between SAP system and SAP
BC, the SAP BC performs a strict user authentication of the user defined on SAP system
side. I.e. when the RFC destination is set up with user/password authentication, the SAP
BC validates the provided user/password information against its own user base. And when
the RFC destination is set up with X.509 client certificate, the SAP BC tries to map the
presented certificate to a SAP BC user as defined under Security  Certificates  Client
Certificates. See the SAP BC Administration Guide, chapter Importing a Client Certificate
and Mapping It to a User (page 135).
If the above succeeds, the RFC call runs under the corresponding SAP BC user ID and is
allowed to execute exactly those Inbound Maps and Routing Rules as is defined in its
assigned ACL(s).
If the login fails, the RFC call is aborted with an exception. There is no fallback to the
default SAPUser!
Using SAP BC with the SAP Cryptographic Library for SNC
The SAP Cryptographic Library is the default security product delivered by SAP for
performing encryption functions in SAP Systems. You can use it for providing Secure
Network Communications (SNC) between SAP Server components. The
sapcryptolib is also used to implement Single Sign-On (SSO). This section
describes the procedure steps that are required to setup the SAP BC Server for SNC
using the sapcryptolib. For more detailed information on the installation of the

SAP AG
sapcryptolib and the generation of PSEs (Personal Security Environment) see

Using the SAP Cryptographic Library for SNC in the SAP Online Documentation (SAP
Library).
To use SAP BC with the SAP Cryptographic Library
1. Install the SAP Cryptographic Library (see SAP Online Documentation)

2. Generate a PSE (Personal Security Environment) for SNC (see SAP Online
Documentation)
3. Create the Server’s Credentials using SAPGENPSE (see SAP Online Documentation)
4. Exchange the security information between the communication partners (servers): see SAP
Online Documentation.
5. Configure your SAP BC Server and the corresponding SAP Application Servers for SNC
use (see Security Options in the section Defining SAP Servers on page 3-4).
6. Optional: Adopt the SECUDIR environment variable (see SAP Online Documentation) to
point to the correct location of your PSE files by modifying the startup script:
• Windows platforms: insert a line in server.bat as follows: after the SETLOCAL line
set SECUDIR=<pse-path>
• Unix platforms: insert a line in server.sh as follows at the very beginning
export SECUDIR=<pse-path>

SAP AG
Authorization Profiles for the SAP Logon User
To restrict the rights of the SAP logon users you should create specific user accounts in
the SAP system with the minimum necessary set of authorizations. If SAP BC is used as
a pure RFC Server, it will only perform very few function callbacks to the calling SAP
System. These callbacks are needed to determine the function interface specification and
structure definitions of the parameters. The same is true for a client user that only
performs those repository lookups. The authorization object for callbacks and lookups
should look like this:
Authorization Object: S_RFC

Authorization Field ACTVT: 16
Authorization Field RFC_TYPE: FUGR
The RFC_NAME field needs to be filled with the following SAP standard function
groups, depending on the SAP System release:
Release Function Groups

3.1G – 3.1I RFC1, SYST, SRFC, SUNI, EDI6, EDI8, EDIF, ARFC, ERFC,
BD11
4.0A – 4.5B RFC1, SYST, SRFC, SYSU, SUNI, SDIF, EDIMEXT, EDI6,
ARFC, ERFC, EDIN
4.6A – 4.6C RFC1, SYST, SRFC, SYSU, SDIF, EDIMEXT, EDI6, ARFC,
ERFC, EDIN
4.6D and higher RFC1, SYST, SRFC, SYSU, SDIFRUNTIME, EDIMEXT,
EDI6, ARFC, ERFC, EDIN
Additionally, when processing IDocs, the following authorization objects have to be

assigned to the SAP Logon User:
S_IDOCDEFT: This object is required for reading IDoc definitions from the R/3 DDIC.
For example, assign the authorization "S_IDCDFT_DIS".
B_ALE_RECV: This object is required for sending IDocs into an SAP system. Fill the
field EDI_MESTYP with a list of the message types of the IDocs to be processed.
Authorization Configuration in the SAP Environment

For Authorization configuration please see SAP BC Security Best Practices Guide,
Chapter 6.
Installing SAP BC according to your Security Policy
The SAP BC can only access SAP Systems for which a SAP alias has been created in the
SAP server list. There is no service available that allows you to execute RFC calls to SAP
Systems that are not defined there.

SAP AG
In addition to this restriction, you can also protect access to SAP Systems in an intranet by
installing an additional firewall between the SAP BC and the SAP Systems or putting the
SAP BC in the DMZ. You can configure the firewall to restrict which SAP Systems can
be accessed from the SAP BC through the SAP router.
Finally, you might even want to completely disallow a SAP BC server in the DMZ to
actively open connections to a SAP System in the intranet. To do so, you need to install
two SAP BC servers, one in the DMZ and one in the intranet. The SAP BC server in the
DMZ can then be configured as a reverse invoke server. Thus, the SAP BC server in the
intranet will establish the connection to the reverse invoke server (inside to outside)
whereas the data still flows synchronously from the outside to the inside. For information
on how to configure reverse invoke please see SAP BC Administration Guide, Chapter 8
(Managing Server Security), p. 135 ff.
References
For further information on how to configure security, refer to the SAP BC Administration
Guide.

SAP AG
Chapter 10: Managing the DDIC Cache
Data Dictionary Cache (DDIC Cache) ................................. 10-13

Viewing Information in the DDIC Cache .............................. 10-13
Removing Information from the DDIC Cache ...................... 10-16

SAP AG
Data Dictionary Cache (DDIC Cache)

The Data DICtionary Cache (DDIC) is a cache that holds information about SAP function
modules, structure definitions, Business Objects, and ALE mappings. The SAP Business
Connector retrieves this information from an SAP server when it performs RFC or BAPI
lookups. To improve performance, the SAP Business Connector caches information it
receives about function modules and structure definitions.
The SAP Business Connector looks up information in the backend’s DDIC about function
modules and structures when:
An RFC, IDoc or BAPI lookup is requested from the Lookup screen or from the
Developer’s SAP menu.
The SAP Business Connector executes a SAP BC service that invokes an RFC or
BAPI on an SAP server or sends an IDoc into an SAP server.
An SAP server executes an RFC that invokes a SAP BC service or sends an IDoc
to the SAP Business Connector.
The SAP Business Connector keeps separate cached function modules, structure
definitions, Business Objects, IDoc definitions and ALE mappings for each SAP server.
When the SAP Business Connector requires specific data, it checks its DDIC cache for
the specific server to determine if the information it requires is already cached. If the
required information is in the DDIC cache, the SAP Business Connector uses the cached
information rather than retrieving it from the SAP system.
The DDIC cache is always active. There are no configuration tasks required to activate it.
When you are developing services, there may be times when the information in the DDIC
cache becomes outdated, for example, if you change an RFC signature on an SAP server.
In these situations, you can use the DDIC cache screens to view the information in the
cache and remove specific function modules or structure definitions from the cache as
necessary without having to restart the SAP Business Connector.
The DDIC cache does not persist through shutdown and restart of the SAP Business Connector.
Viewing Information in the DDIC Cache

Perform one of the following procedures to view information about the function modules,
structure definitions, Business Objects, IDoc definitions and ALE mappings that are in
the DDIC cache.
To view information in the DDIC cache

2 Select the DDIC-Cache tab if it is not displayed.

SAP AG
The SAP Business Connector displays a screen that lists the number of function
modules and structure definitions cached for each SAP server.
The System ID field is the name that was defined when the SAP system was
originally installed. If one or more SAP systems use the same system ID, they will
share the same cache. This would lead to corrupted or truncated data in function
module parameters or tables or in IDoc segments, if the two SAP systems have a
different release and structures, tables and IDoc segments have been changed from
one release to the other.
Therefore, you must not connect two different SAP systems that share the same
System ID to one Business Connector. A setup like this is not supported. It may
work in special circumstances where you can guarantee that all used structure, table
and IDoc definitions are identical in both systems, but you would run such a setup
at your own risk. Much preferable would be to do one of the following:
• Change the System ID of one of the two systems.
Changing the System ID of an installed SAP system is quite difficult and
sometimes even impossible. You may need to consult with SAP support in
this case. But it is very advisable that all SAP systems within the same
network have their own unique System ID.
• Install two separate Business Connectors and have each of the two SAP
systems use one dedicated Business Connector.
For more information about defining SAP servers, refer to Defining SAP Servers on
page 3-4.
3 To view the names of cached function modules for an SAP server, select the number
in the Function cache column for the appropriate SAP server.
4 To view the names of the cached structure definitions for an SAP server, select the
number in the Structure cache column for the appropriate SAP server.
To view the function interface of cached function modules

2 Select the DDIC-Cache tab if it is not already displayed.
3 To view the names of cached function modules for an SAP server, select the number
in the Function cache column for the appropriate SAP server.
4 Select the function module for which you want to see the function interface.
The SAP Business Connector displays a screen that lists the function interface for
the selected function module.

SAP AG
5 To view the structure definition of the displayed parameters, follow the hyperlink in
the Table field. If you want to view the structures directly from the DDIC main
page, follow the instructions below.
To view the structure definition of cached structures

3 To view the names of the cached structure definitions for an SAP server, press the
number in the Structure cache column for the appropriate SAP server.
4 Select the structure for which you want to see the structure definition.
The SAP Business Connector displays a screen that lists the structure definition
for the selected cached structure.
To view the cached business objects

SAP AG

3 To view the names of the cached business objects for an SAP server, press the
number in the Business Object column for the appropriate SAP server.
To view the cached ALE mappings

3 To view the names of the cached BAPIs for an SAP server (for which ALE
information of an SAP System has been checked and extracted), press the
number in the ALE Mappings column for the appropriate SAP server.
The list also contains BAPIs for which no ALE interface has been generated in the SAP
System, but for which the availability has already been checked. This is because the
SAP Business Connector tries only once to retrieve ALE information. If this retrieval
fails, the SAP Business Connector remembers this fact.
Removing Information from the DDIC Cache

If a function module, structure definition, Business Object, IDoc definition or ALE
mapping in the DDIC cache becomes outdated, you can use the following procedures to
remove it from the DDIC cache.
To remove function modules from the DDIC cache

3 To view the names of cached function modules for an SAP server, select the
number in the Function cache column for the appropriate SAP server.
4 To remove a function module from the DDIC cache, press the icon in the
Remove column.

SAP AG
To remove structure definitions from the DDIC cache

3 To view the names of the cached structure definitions for an SAP server, press
the number in the Structure cache column for the appropriate SAP server.
4 To remove a structure definition from the DDIC cache, press the icon in the
Remove column.
To remove Business Objects from the DDIC cache

3 To view the names of the cached business objects for an SAP server, press the
number in the Business Objects column for the appropriate SAP server.
4 To remove a business object from the DDIC cache, press the icon in the
Remove column.
To remove ALE mappings from the DDIC cache


SAP AG
3 To view the names of the cached ALE mappings for an SAP server, press the
number in the ALE Mappings column for the appropriate SAP server.
4 To remove an ALE mapping from the DDIC cache, press the icon in the
Remove column.

SAP AG
Appendix A Package Contents
Package Layout .................................................................... A-2
SAP Business Connector A-1

SAP AG
Package Layout
All of the files relevant to the SAP Business Connector and its persistent state
information are in the sapbc/server/packages/SAP directory. The following table
describes the directories and files that make up the SAP package directory.
Directory Contents
code Contains the SAP Business Connector libraries.
config Contains the following configuration files:

− sap.cnf This file is created when you add your first SAP server using the
SAP Administration interface. It stores server settings, listener settings,
and maps. Back up this file before upgrading your server.
− cbr.cnf (content-based routing). This file contains the configuration
parameters for content-based routing (see p. 8-24).
logs Contains the SAP Business Connector log files.
ns Contains namespace information for the SAP Business Connector built-in

services.
pub, templates Contains files and images comprising the SAP Administration interface.
SAP Business Connector A-2

SAP AG
Appendix B Server Configuration
server.cnf ............................................................................. B-2
SAP Business Connector B-1

SAP AG
server.cnf
This file is created when you start the SAP Business Connector for the first time.
Some of the following statements can be added manually after installing SAP Business Connector.
Shut down the server and back up this file before you edit server.cnf.
As of SAP BC Release 4.6, you can change the values of the server.cnf parameters also
via the Server Administrator UI. Choose Settings -> Extended and select the parameters you
want to edit (see SAP BC Administration Guide 4.8, p.94ff. for details).
The following statements are added automatically, when SAP Business Connector is started for the first
time:
Maximal number of connections in one RFC
watt.sap.connection.poolSize
connection pool to one SAP System (default: 10)
Delay (minutes) until an unused connection to a SAP
watt.sap.connection.timeout
System is timed out (default: 5)
Time interval in seconds between checks (seconds)
watt.sap.connection.timeoutCheckPeriod
whether unused pooled connections have timed out
Delay (seconds) until requests waiting for a connection
watt.sap.connection.waitForPool
from a pool time out in the queue
Time interval (minutes) between checks of the listener.
It is checked whether the RFC Handle is still valid. If
watt.sap.listener.checkTime
the Gateway is running, any inactive Listener is
restarted at the latest after this interval.
Delay (seconds) until a listener responds at the latest to
watt.sap.listener.responseTime
an incoming request.
watt.sap.debug.level Debug level from 1 to 10

watt.sap.debug.facList List of Logging Facilities for the SAP Package.
Change/add the following statements to the server.cnf file to modify its XML creation
mechanisms:
Version of RFC-XML (XRFC) sent. Valid versions: 0.9 and 1.0
watt.sap.rfcxml.version (default).
Version of illegal character escaping in IDoc-XML. Valid
watt.sap.idocxml.escaping
versions: 4.6 and 5.0 (default)
Flag that indicates if the SAP XML dialects should be rendered
watt.sap.xml.prettyPrint pretty printed. (default=true) Set the value to "false" to remove
all unnecessary white space and thus improve performance.
Used for overriding the SAP BC’s encoding of RFC-XML and
IDoc-XML documents. By default, the Business Connector
creates RFC/IDoc-XML documents with the encoding-attribute
set to an encoding corresponding to the SAP system codepage of
watt.sap.xml.encoding the SAP system, from which the RFC/IDoc has been received.
For example, if the SAP system is running under codepage 1100,
then the BC will use encoding=”iso-8859-1” in any XML
headers created from this data. To override this behavior, use the
watt.sap.xml.encoding parameter.

SAP AG
Change/add the following statements to the server.cnf file to increase performance of the message
store
This switch can be set to "true" or "false". If set to "true", there
will be no transaction management for incoming documents. The
documents will not receive an individual transaction ID and their
state cannot be monitored in the transaction list of the message
watt.PartnerMgr.routeOnly
store. Furthermore, the message body will not be stored on disk.
The "routeOnly" switch, when set to "true", will automatically
overwrite the setting of the "watt.PartnerMgr.noMsgStorage"
switch.
Tip:
This switch is offered mainly for compatibility reasons. It is
recommended to rather fine-tune transactional performance via
the other three switches.
This switch can be set to "true" or "false". If set to "true", then

the message body of the incoming document will not be stored
watt.PartnerMgr.noMsgStorage to disk, although a transaction will be created (or maintained) for
the incoming document, and the transaction status can be
monitored later on in the transaction list.
Tip:
As SAP BC itself does not support queuing and replaying
mechanisms there is usually no strong reason to persist the
message body. This is likely done anyway by the applications
which act as a client or recipient during the communication.
Activating this switch reduces the amount of disk space needed
and of course the time it takes to process transactions. It still
allows you to track the transaction status on SAP BC.
The server.cnf parameter watt.PartnerMgr.flushPeriod. It
specifies the time period in minutes, how often the
watt.PartnerMgr.flushPeriod TransactionManager will flush yet unsaved changes in the
transaction cache to the file system.
Default: every 5 minutes.
Tip:
The following settings are recommended:
watt.PartnerMgr.routeOnly=false (or no value at all)
watt.PartnerMgr.noMsgStorage=true
The server.cnf parameter watt.PartnerMgr.flushMaximum

specifies how many unsaved transactions the "flushing Thread"
should save to the file system during one execution. It will stop
after this number, even if there are still more unsaved
watt.PartnerMgr.flushMaximum
transactions in the Cache. This is offered for performance
reasons, so that the server will not spend too much time non-stop
in Cache flushing.
Default: 200.
Status of the Message Store will go to yellow, if the size of one
watt.PartnerMgr.fileSizeWarning of the files xtn.log and xtn_audit.log reaches the given size.
Default value is 204800. Measured in kB.
Status of the Message Store will go to red, if the size of one of
watt.PartnerMgr.fileSizeAlarm the files xtn.log and xtn_audit.log reaches the given size. Default
value is 512000. Measured in kB.
watt.PartnerMgr.sizeWarning Status of the Message Store will go to yellow, if the total number
of transactions reaches the given value. Default value is 50000.
watt.PartnerMgr.sizeAlarm Status of the Message Store will go to red, if the total number of

SAP AG
transactions reaches the given value. Default value is 100000.
Change/add the following statements to the server.cnf to improve security:

Path of the SNC library needed for secure RFC
watt.sap.snclibpath
connections.
When set to True, the server certificate is checked
watt.net.ssl.client.enforceTrust each time an SSL connection is established with
SAP BC as a client.
Change/add the following statements to the server.cnf to use XSLT:

watt.xslt.debug.level Debug level for the XSLT component (Default:
server debug level)
List of XSLT facilities enabled for
watt.xslt.debug.facList
debugging (Default: disable all facilities)
File to log XSLT related messages (Default:
watt.xslt.debug.logfile
packages/SAP/logs/xslt.log)
JAXP properties as defined by the standard
watt.xslt.jaxp.properties (Default:
packages/SAP/config/transformation.properties)
Change/add the following statements to the server.cnf to specify monitoring options:

Set this variable to the directory in which you want
watt.sap.debug.dir to store the SAP log files (default:
packages/SAP/logs)
Flag to decide whether to write basic throughput
watt.sap.throughput information to log. Valid values: true and false
(default)
Switch to turn jARM Monitoring 'on' (default) or
watt.sap.jarm/switch
'off'
Logical system that the Business Connector should
watt.sap.systat01.partnerNumber
use when sending SYSTAT01 IDocs into R/3.
“true” or “false”. Specifies whether the BC should
keep an index with the relations between IDoc
watt.sap.monitorIDocs document numbers and the corresponding
transaction IDs of the IDoc packet. Default is
“false”.

SAP AG
Appendix C Representation of ABAP Types in SAP BC

ABAP Type Description Dictionary Types XML Representation
C character[s] CHAR, CLNT, CUKY, LANG, characters as string
LCHR, UNIT
D Gregorian Calendar date DATS yyyy-MM-dd as string
F IEEE double-precision 64- FLOAT float as string
bit floating point
I 4-byte signed integer INT4 integer as string
N numeric character[s] NUMC, ACCP numeric characters as
string
P decimal number CURR, DEC, QUAN decimal as string
T time TIMS HH:mm:ss as string
X binary octets RAW base64 string
b 1-byte unsigned integer INT1 integer as string
s 2-byte signed integer INT2 integer as string
STRING variable length string STRING string
XSTRING variable length binary RAWSTRING byte[ ]
octets
SAP Business Connector C-1

SAP AG SAP Business Connector API
Appendix D SAP Business Connector API
SAP Client Services.............................................................. D-2

 XRFC Services……………………………………………………D-14
IDoc Services ..................................................................... D-17
IDoc-XML Services ............................................................. D-24
 bXML Services…………………………………………………....D-26
 BAPI Services…………………………………………………….D-28
 Routing Rule Administration Services………………………….D-30
 Transaction Administration Services……………………………D-36
Transport Services..................................................................D-42
XSLT Services........................................................................D-55
Demo Services ................................................................... D-57
IDoc Java API..................................................................... D-60

D-1
SAP SE
SAP Client Services

pub.sap.client:connect
Establishes a connection to an SAP server.
No longer necessary, as connections are now pooled.
Input Parameters
serverName SAP system alias to which the connection is established. The

name must match a configured SAP server alias on the SAP
Business Connector Server.
$client (optional) Client for the session. If no client is specified, the default client
is used.
$user (optional) Username for the session. If no user is specified, the default
user is used.
$pass (optional) Password for the session. If no password is specified, the

default password is used.
$language (optional) Language used during the session. If no language is specified,

the default language is used.
Return Values
This key Contains…
result "Ok" if connection was established successfully.

Example
Use the pub.sap.client:connect service when you want to establish a connection to a target
SAP system. This might be useful for creating a session pool. In the most common
scenarios, it is not necessary to invoke this service explicitly, as it is invoked implicitly
(for example, when a pub.sap.client:invoke or pub.sap.client:invokeTransaction is issued).
SAP Business Connector D-2

SAP SE
pub.sap.client:lockSession
Locks an RFC connection to your SAP BC session so that you will always exclusively use
this RFC connection for subsequent calls.
Input Parameters
serverName SAP system alias on which the session will be locked. The
$client (optional) Client for the session. If no client is specified, the client
specified in the SAP system alias settings is used.
$user (optional) Username for the session. If no user is specified, the user

password specified in the SAP system alias settings is used.

the language specified in the SAP system alias settings is
used.
Return Values
There are no return values
Example
This service locks a backend session so that the current SAP BC session has exclusive
access to that session. This allows executing one or several BAPIs within the backend
session and completing this LUW by triggering a COMMIT WORK command inside the
SAP System. The COMMIT WORK will cause a database commit and start the processing
of the posted data. This service only works with SAP Systems from 4.0A on, because
from that release on (some) BAPIs do not write data directly to the database but use the
posting engine inside the SAP System. The data will not be written to the database until
the client triggers a COMMIT WORK command. In order to call a BAPI which uses this
mechanism, it is required to perform the following steps on the SAP Business Connector:
1. Call the pub.sap.client:lockSession service in order to get an exclusive connection to the
SAP System.
2. Perform the BAPI calls.
3. Call the pub.sap.bapi:commit or pub.sap.bapi:rollback service
4. Call the pub.sap.client:releaseSession service in order to release the exclusive
connection to the SAP System and clean up used resources on the SAP Business
Connector and in the backend session.

SAP SE
pub.sap.client:releaseSession
Releases a locked session on a SAP server.
Input Parameters
serverName SAP system alias on which the locked session is located. The
user is used.


Return Values
There are no return values
Example1
The service will release a session after a commit work or rollback work command has
been triggered inside the SAP System. This service only works with SAP Systems from
4.0A on, since from that release on (some) BAPIs don't write data directly to the database
but use the posting engine inside the SAP System. In order to call a BAPI which writes
data, it is required to perform the following steps on the Business Connector:
1. Call the pub.sap.client:lockSession service in order to get a exclusive connection to the
SAP System.
2. Perform the BAPI calls.
3. Call the pub.sap.bapi:commit or pub.sap.bapi:rollback service
4. Call the pub.sap.client:releaseSession service in order to release the exclusive
connection to the SAP System and clean up used resources on the SAP Business
Connector and in the backend session.
Example2
You also need this service if you want to lock and change a certain database object. To do
this, please proceed as follows:
1. Call the pub.client:lockSession service in order to get an exclusive connection to an SAP
system.
2. Lock an object by calling a BAPI_*_ENQUEUE.
3. Make your changes by invoking other BAPIs.
4. Release the object by calling a BAPI_*_DEQUEUE.

SAP SE
5. Call the pub.client:releaseSession service.
pub.sap.client:invoke
Invokes an RFC function module in synchronous mode on a given SAP server.
Input Parameters
This service also needs the inputs (imports and tables) required by the function module.
serverName Server alias from the server list on which the function module
will be invoked.
$rfcname Name of the function module to be invoked.
user is used.


Return Values
This service returns the outputs (exports and tables) returned by the function module.
$rfctime Time (ms) spent within the RFC library to complete the
invocation.
$runtime Total invocation time (ms), including processing time within the
backend R/3 system.
$encoding MIME-compliant character set corresponding to the session’s

SAP code page.
$call flag indicating whether pipeline represents a request (true) or a

response (false) of a function module
Example
This service is used when you are directly calling an RFC on an SAP system without
using an outbound map. (When an outbound map is used, this service is invoked
implicitly.)

SAP SE
pub.sap.client:invokeTransaction
Invokes a function module via tRFC on a given SAP server.
Input Parameters
serverName SAP server alias for the SAP server on which you want to
invoke the function module. The alias must match a configured
SAP server alias on SAP Business Connector Server.
$rfcName Name of the Remote Function Call.
$queueName (optional) Name of the SAP system inbound queue. Specify a value in
case of a qRFC scenario
user is used.


Return Values
backend R/3 system.
invocation.

SAP code page.
$call Flag indicating whether pipeline represents a request (true) or

a response (false) of a function module.

SAP SE
pub.sap.client:createTID
Call this service if you want to obtain a transaction ID (TID; which is a GUID) that
conforms to the format of SAP TIDs. The obtained TID can be used for
pub.sap.client:invokeTransaction and pub.sap.client:confirmTID.
The pub.sap.transport.ALE:OutboundProcess service performs the function of both the
pub.sap.client:createTID and pub.sap.client:invokeTransaction services. For IDocs it is
recommended that you use the pub.sap.transport.ALE:OutboundProcess or
pub.sap.client:sendIDoc services rather than invoking pub.sap.client:createTID and
pub.sap.client:invokeTransaction.
Input Parameters
serverName SAP system alias on which the TID is created. This name must
match a server list entry.
user is used.


Return Values
$tid Contains the TID.
Example
This service is used in tRFC client scenarios, which require a transactional ID (TID)
uniquely identifying the transaction. See also pub.sap.client:confirmTID.
pub.sap.client:confirmTID
Confirms the transaction specified by the TID on the specified SAP system. This service
must be called after an invokeTransaction in order to clean up the transaction status
keeping entries on the target system.
Input Parameters

SAP SE
serverName SAP system alias on which the transaction is confirmed. The

name must match a server list entry.
$tid Transaction ID to be confirmed.
user is used.


Return Values
There are no return values.
Example
This service is used in tRFC client scenarios in order to confirm a transaction which has
been executed successfuly.
1. Invoke pub.sap.client:createTID. This service creates an SAP-conformant TID.
It is necessary to have one, otherwise you cannot invoke the function module with
pub.sap.client:invokeTransaction. If you have already obtained a TID, you should use
that one in order to guarantee that the transaction is executed only once.
2. Invoke pub.sap.client:invokeTransaction. This service invokes the given
function module as a tRFC on the SAP system specified by serverName. The TID
is passed as a parameter on this call.
3. Invoke pub.sap.client:confirmTID. Confirms that the transaction has completed.
Pass the same serverName and $tid value on this call.
pub.sap.client:getAttributes
Connects to the given SAP system and returns interesting information about this session.
Input Parameters
serverName Alias of the SAP system, whose attributes are to be

determined. The name must match a server list entry.

SAP SE
user is used.


Return Values
Record containing session information (RFC Attributes):

Hostname (or IP) of the machine the Business Connector is
ownHost running on
Hostname (or IP) of the machine the SAP system is running on
partnerHost
System number of the SAP system
systemNumber
Unique three-letter-ID of SAP system (in local network)
systemID
Client the session is connected to
client
SAP user that has connected with this session
user
Logon language
language
ISO name for logon language
ISOLanguage
SAP codepage this connection is using
ownCodepage
SAP codepage the SAP system is running on
partnerCodepage
Version of the loaded RFC library used by the Business
ownRelease Connector
Release of the SAP system
partnerRelease
Kernel release of the SAP system
kernelRelease
RFC type of the partner; R/3 (3), R/2(2) or external RFC server
partnerType (E)
Flag indicating whether trace is turned on(true) or off(false) for
trace this connection
RFC type of the Business Connector; should always be E
ownType
Role of the Business Connector in this call; should always be
rfcRole C (for client)

SAP SE
CPIC ID of the connection (low level protocol information)

CPICConversationID
IANA-encoding that is equivalent to the SAP codepage used,
encoding e.g. ISO-8859-1
charset that is equivalent to the SAP codepage used, e.g.
charset ISO8859_1 (used in Java constructors)
number of maximum bytes used per char in the codepage
bytesPerChar
pub.sap.client:getFunctionInterface
Looks up the function interface definition of an RFC function module in the given SAP
system.
Input Parameters
$rfcname Function module for which the interface definition is looked up.
serverName Alias of the SAP system, in whose DDIC you want to look up
the function module definition. The name must match a server
list entry.
user is used.


Return Values
Record list containing all parameter related information:

Class of parameter; I (importing), E (exporting), T (table), X
paramClass (exception).
Name of the parameter in the function interface.
parameter
Name of the table in the SAP system the parameter is referring
tabName to.

SAP SE
Type of the parameter (e.g. CHAR, INT, FLOAT,

type STRUCTURE, TABLE, ...)
Internal length in bytes of the parameter.
length
Only relevant for decimal types; number of decimals used.
decimals
Flag indicating whether parameter is optional.
optional
pub.sap.client:getStructureDefinition
Looks up the structure definition of an SAP structure in the given SAP system.
Input Parameters
structName Structure name for which the definition is looked up.
serverName Alias of the SAP system, in whose DDIC you want to look up
the structure definition. The name must match a server list
entry.
user is used.


Return Values
Record list containing all field related information.
fieldName Name of the field.

Name of the table/structure in the SAP system the field is
tabName (optional) referring to.
position Position within structure.

SAP SE
offset Offset in bytes to this field.
length Internal length in bytes.
decimals Only relevant for decimal types; number of decimals used.
type Type of the field (e.g. CHAR, INT, FLOAT, STRUCTURE,

TABLE, ...)
tabLength Length of the structure when used in a table. This might differ
from the sum of all field lengths, as the number types have to
be aligned to memory segments.
pub.sap.client:sendIDoc
Sends an IDoc to a given SAP server.
Input Parameters
serverName SAP server alias of the SAP server to which you want to send
the IDoc. The alias must match a configured SAP server alias
on SAP Business Connector Server.
iDocList Contains the IDoc(s) as object of the Java IDoc Class Library.
user is used.


Return Values
backend R/3 system.

SAP SE
invocation.

SAP code page.
$call Flag indicating whether pipeline represents a request (true) or

a response (false) of a function module.
pub.sap.client:ping
Checks the response time of an SAP system.
Input Parameters
serverName Alias of the SAP system, which shall be pinged. The name
must match a server list entry.
user is used.


Return Values:
responseTime Response time of the SAP system.

SAP SE
XRFC Services
pub.sap.rfc:encode
Converts the data of an RFC call to an XML string in a format specified by the SAP
RFC-XML (XRFC) specification.
Input Parameters
This service needs the function module’s input data (in case of a call) or output data (in
case of a response) to be present in the pipeline in Values/IData representation.
repServerName SAP system used as a repository. This name must match a

-OR- server list entry.
serverName
$encoding Specifies the encoding used in the output document's XML

header, e.g. iso-8859-1
$call This flag specifies whether the pipeline should be interpreted

as a call (true) or as a response (false)
$envelope bXML, XRFC (RFC-XML) or SOAP. Specifies the type of

document to be generated.
encodeTo This flag specifies whether the output should be a Java String
(xmlData) or a byte[] (bytes).
Return Values
xmlData Contains the RFC-XML representation of the pipeline as a

string, if encodeTo was set to “string”.
bytes Contains the RFC-XML representation of the pipeline as a byte

array, if encodeTo was set to “bytes”.
contentType The content type associated with the generated document

(e.g. application/x-sap.rfc)
Example
Use this service for creating RFC-XML corresponding to the pipeline and forwarding it
to another BC or web server (for example, via HTTP). This is done in the XML
transport’s Outbound Process for function modules.

SAP SE
pub.sap.rfc:decode
Converts an RFC-XML (XRFC) document to an IData object that will be in the correct
format to be passed to an SAP system.
Input Parameters
The service searches the pipeline for input data in the following order: xmlData, bytes
and finally node. If one of these keys is found, the search stops and the found input will
be decoded. For example, if the pipeline contains two RFC-XML documents, node and
xmlData, then only xmlData will be decoded and node will not be processed.
bytes (optional) Byte array containing the RFC-XML document to be decoded.
node (optional) Document object representing the XRFC data (you will get a
node, e.g. when putting an XML file via FTP with extension
.xml).
xmlData (optional) String containing the RFC-XML document to be decoded.
Return Values
IData object corresponding to the RFC-XML document.
$encoding Specifies the encoding used in the input document's XML
Example
This service can be used when an RFC-XML document is posted to the server in a
variable.
pub.sap.rfc:createTemplate
Creates an RFC-XML (XRFC) template for the specified function module
Input Parameters
repServerName SAP server alias for the SAP server that is used as a
repository. The alias must match a configured SAP server
alias on the SAP Business Connector Server.
$encoding Specifies the encoding used in the output document's XML

$rfcname Function module for which you want to create the template.

SAP SE
$call This flag specifies whether a call template (true) or a response

template (false) is created.
$envelope bXML, XRFC (RFC-XML) or SOAP. Specifies the type of

template generated.
Return Values
xmlData Contains the RFC-XML template as a string.
Example
Use this service to create templates for testing purposes. This service is used in the Lookup
screen.

SAP SE
IDoc Services
Due to the integration of the Java IDoc Class Library into SAP BC 4.8 some service
parameters in this part have changed. They may contain the additional parameter iDocList
(an IDocDocumentList object) that replaces or extends the parameters
IDOC_CONTROL(_REC_40) and IDOC_DATA(_REC_40).
pub.sap.idoc:encodeSDATA
Converts every SDATA field from a structured record to byte array. This service is
usually called prior to sending an IDoc to an SAP system via
pub.sap.client:invokeTransaction.
Note: starting with release 4.7 there is a new client service pub.sap.client:sendIDoc that
allows to send the iDocList directly. The encodeSDATA service is no longer necessary.
Input Parameters
This service requires the following input parameters to be present in the pipeline.
Note that this service handles both IDoc versions 2 and 3. The difference between the two
is that, for IDocs version 2, the service looks for IDOC_CONTROL and IDOC_DATA in
the pipeline. For IDocs version 3, it looks for IDOC_CONTROL_REC_40 and
IDOC_DATA_REC_40.
IDOC_CONTROL Both keys are Record list (Table) objects containing the
IDOC_DATA control and data tables for the IDoc.
or The SDATA field is a Values object containing the keys and
IDOC_CONTROL_REC values from the segment table (the name of the segment
40 table is specified by the SEGNAM field).
IDOC_DATA_REC40
iDocList Contains the IDoc(s) as object of the Java IDoc Class

Library.
serverName Server alias which is used as repository for structure

information about the IDoc.
Return Values
or The SDATA field is a 1000-byte field. At this point, the IDoc
IDOC_CONTROL_REC in the pipeline is ready for sending to an SAP system via
40 pub.sap.client:invokeTransaction.

SAP SE
IDOC_DATA_REC40
pub.sap.idoc:decodeSDATA
Converts the SDATA field from raw byte array to a structured record (with keys and
values corresponding to the segment table). This service was usually called immediately
after receiving an IDoc from the SAP system in a Java service, for example.
With Release 4.7, the service is only required if you receive an IDoc in the tables
representation from a sending system (e.g. in an Inbound Map for
IDOC_INBOUND_ASYNCHRONOUS).
Input Parameters
Note that this service handles both IDoc versions 2 and 3. The difference between the
two is that, for IDocs version 2, the service looks for IDOC_CONTROL and
IDOC_DATA in the pipeline. For IDocs version 3, it looks for
IDOC_CONTROL_REC_40 and IDOC_DATA_REC_40.
or This is state of the Values object that is passed to a Java
IDOC_CONTROL_REC service from the SAP system.
40
IDOC_DATA_REC40 At this point, the SDATA field of each segment consists of a
1000-byte field.
serverName Server alias which is used as repository for structure

information about the IDoc.
Return Values

Library.
pub.sap.idoc:transformFlatToHierarchy
Reformats an IDoc from flat RFC format to hierarchical format which represents a
hierarchical structure of an IDoc-XML document that can be used for flow mappings.
Deprecated: use pub.sap.idoc:iDocToRecord instead.
Input Parameters

SAP SE
or The SDATA field is now an orderly Values object
IDOC_CONTROL_REC40 containing the keys and values from the segment table
IDOC_DATA_REC40 (the name of the segment table is specified by the
SEGNAM field).

Library.
conformsTo (optional) Name of the record structure of the IDoc. The record
structure is used as a template to discriminate between
records and record lists. Without conformsTo, all tables
in the hierarchical structure will be record lists.
Return Values
boundNode IDoc in hierarchical structure.
pub.sap.idoc:transformHierarchyToFlat
Reformats an IDoc from hierarchical format to flat RFC format.
Deprecated: use pub.sap.idoc:recordToIDoc instead.
Input Parameters
This service requires the following input parameters from the Values object.
boundNode IDoc in hierarchical structure. Note, this is how the

pub.web:documentToRecord service returns an IDoc
when receiving an IDoc-XML document with content-type
text/xml.
Return Values

Library.

SAP SE
pub.sap.idoc.routing:registerService
This service registers a given service with the routing manager. The best way to use it is to
invoke it in a replication or startup service.
Input Parameters
This key… Must specify…
msgType The message type of the IDoc for which you want to register a content-
(global) service will be registered.
service The complete namespace reference of the service to register (format:

folder.subfolder:servicename).
inbound Flag that indicates whether to register an inbound (default) or an outbound

service.
Return Values
This key… Contains…
activated Flag that indicates whether the service could be activated as routing
service.
activeService Present only if activated==false. In this case it contains the service that is
currently active or $none if all registered services are deactivated.
pub.sap.idoc.routing:unregisterService
This service unregisters a given service from the routing manager.
Input Parameters
msgType The message type of the IDoc for which you want to unregister a content-
(global) service will be unregistered.
service The fully specified service to unregister.
inbound Flag that indicates whether to unregister an inbound (default) or an outbound

service.
Return Values

SAP SE
wasActive Flag that indicates whether the unregistered service was the active routing
service.
pub.sap.idoc:encodeString
Converts an IDoc to flat file format equivalent to the format that is used by the file port of
an SAP system.
Note: When saving to a file, make sure the string is saved with correct encoding.
Input Parameters
serverName Server alias to be used as repository for structure information

about the IDoc.
IDOC_DATA control and data tables for the IDoc. The SDATA field has to
be a record containing the keys and values from the segment
or
table (the name of the segment table is specified by the
IDOC_CONTROL_REC40 SEGNAM field).
IDOC_DATA_REC40
Return Values
iDocString The IDoc in flat file format as String.
pub.sap.idoc:decodeString
Parses an IDoc flat file in the format that is used by the file port of an SAP system and
creates an IDoc object from it.
Input Parameters
serverName Server alias which is used as repository for structure information

about the IDoc.
iDocString The IDoc in flat file format as string.
Return Values

SAP SE
pub.sap.idoc:iDocToRecord
Generates a boundNode from an IDoc object. The boundNode can then be used to
perform mappings in Flow language. This function is similar to the service
pub.sap.idoc:transformFlatToHierarchy.
Input Parameters
conformsTo Name of the record structure of the IDoc. The record structure
is used as a template to discriminate between records and
record lists. Without conformsTo, all tables in the hierarchical
structure will be record lists.
Return Values
pub.sap.idoc:recordToIDoc
Complementary service to pub.sap.idoc:iDocToRecord.
Input Parameters
Return Values
iDocList Contains the IDoc(s) as object of the Java IDoc Class Library,
ready to be sent into R/3 via pub.sap.client:sentIDoc.

SAP SE
pub.sap.idoc:iDocToTables
Converts an IDoc object into table format, so that it can be sent to a SAP BC server 4.6
via B2B transport. (The BC 4.6 does not include the Java IDoc Class Library, so can’t
work with IDoc objects.)
Input Parameters

Library.
Return Values
IDOC_DATA control and data tables for the IDoc. The SDATA field is
now an orderly Values object containing the keys and
or
values from the segment table (the name of the segment
IDOC_CONTROL_REC40 table is specified by the SEGNAM field).
IDOC_DATA_REC40
pub.sap.idoc:tablesToIDoc
Complementary service to pub.sap.idoc:iDocToTables.
Input Parameters
IDOC_DATA control and data tables for the IDoc. The SDATA field
needs to be a record containing the keys and values from
or
the segment table (the name of the segment table is
IDOC_CONTROL_REC40 specified by the SEGNAM field).
IDOC_DATA_REC40
Return Values
Contains the IDoc(s) as object of the Java IDoc Class

iDocList Library.

SAP SE
IDoc-XML Services
pub.sap.idoc:encode
This Service converts an IDoc object to an XML document in a format specified by the
SAP IDoc-XML Specification.
Input Parameters
This service requires one the following input parameters to be present in the pipeline.
IDOC_DATA control and data tables of the IDoc.
or The SDATA field needs to be a Record containing the keys
IDOC_CONTROL_REC40 and values from the segment table (the name of the segment
IDOC_DATA_REC40 table is specified by the SEGNAM field).
iDocList Alternatively, the input can be an IDoc object.
$encoding Specifies the encoding to be used in the output document's

XML header, e.g. iso-8859-1
Return Values
xmlData The IDoc XML document in string format, if encodeTo was

set to “string”. The XML format is consistent with the SAP-
XML specification.
bytes The IDoc XML document in byte array format, if encodeTo

was set to “bytes”. The XML format is consistent with the
SAP-XML specification.
Example
This service is most often used when you want to receive an IDoc from an SAP system
and convert it to XML.

SAP SE
pub.sap.idoc:decode
Service that converts an XML string in a format specified by the SAP-XML
Specification into an IDoc object ready to be sent into an R/3 system (using
pub.sap.client:sendIDoc).
Input Parameters
This service requires one of the following input parameters to be present in the pipeline.
It searches the pipeline for input in the following order: xmlData, bytes and finally node.
The first input found is processed and any additional inputs are neglected.
bytes (optional) Byte array containing the IDoc-XML data to be decoded.
node (optional) Document object representing the IDoc-XML data. (You'll get
a node, e.g. when putting an XML file via FTP with extension
.xml).
xmlData String. The IDoc in XML format. The XML format is

consistent with the SAP-XML specification.
Return Values
Note that this service handles both IDoc versions 2 and 3. If the tag for the IDoc control
header is “EDI_DC” in the XML, this service converts it into a version 2 IDoc. If the tag
for the IDoc control header is “EDI_DC40” in the XML, this service converts it into a
version 3 IDoc.
$encoding Returns the encoding used in the input document's XML header,
e.g. iso-8859-1
Example
This service is the first service called when you want to send an IDoc-XML document to
an SAP system. The following is a sequence of service calls that take an IDoc in XML
form, convert it to an IDoc object and then fire it into the SAP system:
1. Invoke this service (pub.sap.idoc:decode). This takes the input xmlData (the XML
String) and creates an IDoc object that is ready to be sent into the SAP system.
2. Invoke pub.sap.client:createTID. This service returns a transaction ID, which can be
used for sending the IDoc into the SAP system. Note: Store this transaction ID, so
that in case of errors you can later resend the IDoc using the same transaction ID.
3. Invoke pub.sap.client:sendIDoc. This service requires the IDoc object and the
serverName to send the IDoc to.
4. Invoke pub.sap.client:confirmTID in case the previous call was successful. This
cleans up the receiving system’s ARFCRSTATE table. Note: if the Business
Connector is the middle-tier in a multi-tier environment, the confirmTID step should
not be invoked here, but in a separate Service triggered explicitly by the first-tier

SAP SE
system! Otherwise duplicate postings may result. See also the Partner Manager
chapter about how to achieve end-to-end transactional security.
bXML Services
pub.sap.bapi:encode
Converts a BAPI call represented in the pipeline to an XML string in a format specified
by the SAP bXML specification.
Input Parameters
$object Name of the business object to encode.
$bapi Name of the BAPI that is encoded.
$encoding(optional) Specifies the encoding to be used in the output document's

XML header, e.g. iso-8859-1.
$call(optional) This flag specifies whether the pipeline should be interpreted

as a call (true) or as a response (false)[default].
$abapexception(optional) If this object is in the pipeline, an Exception document will be

created.
$metabapi(optional) Contains metadata information about the BAPI, which should

be encoded.
Return Values
xmlData The bXML document in string format, if encodeTo was set to

“string”. The XML format is consistent with the SAP-XML
specification.
bytes The bXML document in byte array format, if encodeTo was

set to “bytes”. The XML format is consistent with the SAP-XML
specification.

SAP SE
pub.sap.bapi:decode
Decodes bXML documents and generates a corresponding pipeline. The service searches
the pipeline for input in the following order: xmlData, bytes and finally node. The first
input found is processed and any additional inputs are neglected.
Input Parameters
xmlData (optional) A document in bXML format as a string.
bytes (optional) Byte array containing the data to be decoded as bXML.
node (optional) Document object, that represents the bXML data (you'll get a
node, e.g. when putting an XML file via FTP with extension
.xml).
$encoding(optional) Specifies the encoding used for the strings, e.g. iso-8859-1.
Return Values
No return values.
pub.sap.bapi:createTemplate
Generates a bXML document template for the definition of a BAPI in an SAP system.
Input Parameters
repServerName or SAP server alias for the SAP server that is used as a
serverName repository. The alias must match a configured SAP server
alias on the SAP Business Connector Server.
Note: one of the parameters must be specified. As
repServerName is primary, we recommend using this
parameter
$objectName Name of the business object to encode.
$bapiName Name of the BAPI to encoded.
$encoding(optional) Specifies the encoding to be used in the output document's

XML header, e.g. iso-8859-1.
$call(optional) This flag specifies whether a call template (true) or a response

template (false) is to be created.

SAP SE
Return Values
xmlData The bXML template for the BAPI as a string.
BAPI Services
pub.sap.bapi:commit
Commits a currently pending LUW in the backend session, i.e. it persists the changes
being done during one or more preceding BAPI calls.
Note: You need to use pub.sap.client:lockSession/releaseSession to make sure the current SAP
BC session keeps an exclusive lock on one particular SAP system session.
Input Parameters
serverName SAP system used. This name must match a server list entry.
is used.
user is used.


wait (optional) Flag indicating whether the call should wait until the database
commit is finished. This is necessary, if you want to use the
changed data immediately afterwards in further calls from the
SAP BC. Otherwise the following may happen: first SAP BC
call creates an order in the backend system and calls commit.
The commit work is running in a separate update work
process, and before it is finished, a second call from the BC
comes in trying to add an item to the above order. As the order
is not yet “visible” on the DB, the second call unexpectedly

SAP SE
fails with “order number not found”…
Return Values
Return Return code in BAPI style, indicating the success/failure of the

commit.
pub.sap.bapi:rollback
Rolls back all changes in the current backend LUW. See also commit.
Note: You need to use pub.sap.client:lockSession/releaseSession to make sure the current SAP
BC session keeps an exclusive lock on one particular SAP system session.
Input Parameters
serverName SAP system used. This name must match a server list entry.
is used.
user is used.


Return Values
Return Return code in BAPI style keeping the success/failure of the

rollback.

SAP SE
Routing Rule Administration Services
wm.PartnerMgr.gateway.admin:addRoutingRule
This service creates a new routing rule for the given sender/receiver/msgType triple. If a
routing rule for that key already exists, an exception is thrown. Any of the optional input
parameters supplied with the invoke are already added to the routing rule. If both
"transport" and "transportParams" are present, the Flow Service corresponding to this
routing rule is generated and thus ready to be used.
Input Parameters
sender Sender key
receiver Receiver key
msgType Message Type key
preService Pre-processing service
postService Post-processing service
transport The transport to use for sending the messages. The standard
Business Connector comes with the following Transports:
"FTP Outbound Service", "XML", "ALE (R/3 IDOC)", "RFC",
"Email Outbound Service", "BAPI", "B2B Service". Others may
be registered by add-on Packages.
flow (optional) Name under which the corresponding routing rule service
should be generated. Specify this parameter, if one of the
sender/receiver/msgType keys contains a parameter, which
cannot be used in a file name of the host's file system. If "flow"
is not specified, the default name
wm.PartnerMgr.flows.<sender>.<receiver>:<msgType> is
used for the generated Flow Service.
package (optional) Package into which the Flow Service should be generated. If
not specified, the "Default" package is used.
enabled "true" or "false". If set to "false", the routing rule will not be
used for routing incoming messages, even if the routing rule is
already functional.
aclgroup Protects the generated routing rule Flow Service with the given
ACL. Default is NONE.
forwardConfirmEvent "true" or "false" according to whether this routing rule should

try to pass a "Confirm Event" for a TID on to the receiver of the
actual message.

SAP SE
comment Arbitrary string for your personal usage.
transportParams A Record containing detailed destination parameters for the

chosen "transport". For example, the "FTP Outbound Service"
needs a Record containing the keys "serverhost", "serverport",
"username", "password", etc. See "Overview of Transports" for
more details.
Return Values
None.
wm.PartnerMgr.gateway.admin:editRoutingRule
Updates/completes fields of the routing rule given by the sender/receiver/msgType triple.
If the routing rule for that key does not exist, an exception is thrown. Any of the optional
input parameters supplied with the invoke are used to complete/override fields of the
routing rule. If both, the "transport" and "transportParams" of the routing rule are
complete, the Flow Service corresponding to this routing rule is (re-)generated and thus
ready to be used.
Input Parameters
sender Sender key
flow Name under which the corresponding routing rule service

should be generated. Specify this parameter, if one of the
sender/receiver/msgType keys contains a parameter, which
cannot be used in a file name of the host's file system. If "flow"
is not specified, the default name
wm.PartnerMgr.flows.<sender>.<receiver>:<msgType> is
used for the generated Flow Service.

SAP SE
package Package into which the Flow Service should be generated. If

not specified, the "Default" package is used.
already functional.
aclgroup Protects the generated routing rule Flow Service with the given
ACL. Default is NONE.
forwardConfirmEvent "true" or "false" according to whether this routing rule should

try to pass a "Confirm Event" for a TID on to the receiver of the
actual message.
transportParams A Record containing detailed destination parameters for the

more details.
Return Values
None.
wm.PartnerMgr.gateway.admin:removeRoutingRule
This service deletes a routing rule.
Input Parameters
sender Sender key
Return Values
None.

SAP SE
wm.PartnerMgr.gateway.admin:disableRoutingRule
Disables a routing rule, so that it is no longer used for routing incoming messages. But the
routing rule is not deleted, so that you can later enable it again, when messages for this
sender/receiver/msgType key should be routed.
Input Parameters
sender Sender key
Return Values
None.
wm.PartnerMgr.gateway.admin:enableRoutingRule
Enables a previously disabled routing rule.
Input Parameters
sender Sender key
Return Values
None.
wm.PartnerMgr.gateway.admin:listRoutingRule
Gives a sorted list of all routing rules that match the given selection filter. The filter
parameters may contain the wildcards "*" to match any number of characters and "?" to
match exactly one character. By preceding the filter with a "^", the filter will be
“inverted”. The search conditions are combined with a logical AND. Example: setting
"senderFilter" to A*? will display only those routing rules, whose sender starts with "A"
and has at least one more character after the "A".
Input Parameters

SAP SE
key Key by which to sort the routing rules. One of "sender",

receiver", "msgType", "enabled", "tranport", "destination".
direction Sort the result "ascending" or "descending"
senderFilter A search pattern for "sender".
receiverFilter A search pattern for "receiver".
msgTypeFilter A search pattern for "msgType".
Return Values
routingRules A RecordList containing one entry for each selected routing

rule with fields similar to the output of getRoutingRule
wm.PartnerMgr.gateway.admin:getRoutingRule
Reads the configuration of the given routing rule.
Input Parameters
sender Sender key
Return Values

SAP SE
flow Name under which the corresponding routing rule service has
been generated.
package Package into which the Flow Service has been generated
already functional.
aclgroup ACL protecting the generated routing rule Flow Service.
forwardConfirmEvent "true" or "false" according to whether this routing rule tries to

pass a "Confirm Event" for a TID on to the receiver of the
actual message.
lastChangedBy Username of the last changer of this routing rule.
lastChangedOn Time and date, when this routing rule was last changed.
transportParams A Record containing detailed destination parameters of the

more details.
wm.PartnerMgr.gateway.admin:listTransports
Returns a list of the currently registered transports.
Return Values
transports A RecordList containing one entry for each transport, with the
name of the Transport and a URL to a Service for configuring
this transport (if any).
Note: The following administrative Services in wm.PartnerMgr.gateway.admin should not be used

by applications: generateDefaultName, generateEditTransportTemplate, getMenu (are used
internally by the Administrator UI), startup, shutdown (are used by the BC Server
startup/shutdown routine).

SAP SE
Transaction Administration Services
wm.PartnerMgr.xtn.admin:list
Returns a list of transactions, which can either be a new search in the Message Store, the
result of a previous search (i.e. the current selection), the next or previous page of the
current selection or the sorting of the current selection.
Input Parameters
mode One of the following:

"List" (or empty): the current page of the current selection (if
there is any).
"Sort": sort the current selection by the given "key".
"Update Search": perform a new search in the Message Store
based on the given filter.
"Previous Page": previous page of the current selection (if
there is any).
"Next Page": next page of the current selection (if there is
any).
lowerTime Used in the mode "Update Search". Only transactions which
are newer than this time are selected. The format of this field
should be the same as the one defined under "Settings 
Logging  Log Timestamp Format".
upperTime Used in the mode "Update Search". Only transactions which

are older than this time are selected. The format of this field
should be the same as the one defined under "Settings ->
Logging  Log Timestamp Format".
tidFilter Used in "Update Search" mode. Only transactions whose TID

matches the given filter are selected.
senderFilter Used in "Update Search" mode. Only transactions whose

sender matches the given filter are selected.
receiverFilter Used in "Update Search" mode. Only transactions whose

receiver matches the given filter are selected.
msgTypeFilter Used in "Update Search" mode. Only transactions whose

msgType matches the given filter are selected.
stateFilter Used in "Update Search" mode. Only transactions whose state

matches the given filter are selected.
maxNumber The search result (or current selection) is partitioned into

pages of size "maxNumber". The search result is not returned

SAP SE
as a whole, but on a page by page basis. Default is 50. The

"maxNumber" parameter is kept for following invocations of
"list", until it is changed again.
key Used in "Sort" mode. The current selection of transactions can

be sorted by "date", "$tid", "sender", "receiver", "msgType" or
"state".
direction Used in "Sort" mode. One of "ascending" or "descending".
Return Values
transactions A RecordList containing one Record with detail information for

each transaction. The following keys are always included:
"$tid", "sender", "receiver", "msgType", "date" (the creation
date/time of the transaction, formatted in the usual "Log
Timestamp Format"), "state", "lastStateChange" (the date/time,
when the state of this transactions was last changed,
formatted in the usual "Log Timestamp Format"), "flow"
(inbound service, which received this message), "lastError"
(the last error that happened during processing this
transaction).
The following internal information is also given: "timestamp"
(same as "date", but in milliseconds since 1970-01-01
00:00:00), "stateChange" (same as "lastStateChange", but in
milliseconds since 1970-01-01 00:00:00).
The following information is available, if the transaction in
question is an IDoc and the Business Connector has been
setup for either "IDocTrace" (watt.sap.monitorIDocs=true) or
"SYSTAT01 Status update": "sourceSys" (Logical System from
which this IDoc packet came, i.e. the value of SNDPRN in the
IDoc control record), "docNums" (a list of document numbers
of all IDocs that were contained in this IDoc packet, i.e. the
value of DOCNUM from the control records).
maxNumber The currently used page size for displaying the search result.
totalTransactions Total number of all transactions in the Message Store
currentlySelected Number of transactions in current selection
currentPage The number of the page, which the "transactions" RecordList

is currently holding.
totalPages Total number of pages in the current selection.
fileSizeXtn Size of the file config\xtn.log

SAP SE
fileSizeXtnAudit Size of the file config\xtn_audit.log
status "green", "yellow” or "red", depending on whether one of the

two xtn log files has reached a certain limit. (If these files grow
too large, the performance of the SAP BC degrades. In this
case you should shrink the message store using
wm.PartnerMgr.xtn.admin:shrinkStore.). The limits for when
the status should switch to yellow or red, can be customized
using server.cnf parameters. See Appendix B for
details.
wm.PartnerMgr.xtn.admin:get
Returns detail information for a single transaction.
Input Parameters
$tid The TID of the transaction.
Return values
sender Sender key
date Date/time of creation (formatted in the usual "Log Timestamp

Format").
state Current state
lastStateChange Date/time of last state change (formatted in the usual "Log

Timestamp Format").
lastError The last error that happened during processing of this

transaction.
auditLog A RecordList of messages keeping track of all events that

occurred during processing of this transaction.

SAP SE
wm.PartnerMgr.xtn.admin:getMessage
Returns the pipeline containing the actual message body. Note: this Service will only
work, if the storing of message bodies has not been disabled (i.e.
watt.PartnerMgr.noMsgStorage=true has not been added to server.cnf).
Input Parameters
$tid The TID of the transaction
Return values
Depending on transaction.
wm.PartnerMgr.xtn.admin:mapDocNumToTID
If the Business Connector has been setup for "IDocTrace" (watt.sap.monitorIDocs=true),
this Service can be used to find the transaction IDs of IDocs for which only the document
number (DOCNUM from IDoc control record) is known.
Input Parameters
sourceSystem The Logical System, from which these IDocs came from. This
is the value SNDPRN from the IDoc control record.
docNumTable A RecordList with two columns. The first column (DOCNUM)

can be filled with IDoc document numbers, the second column
(TID) should be left empty. For each DOCNUM this service
then fills in the transaction ID, under which this IDoc can be
found in the Message Store, or null, if the IDoc cannot be
found. (Usually this TID will be the tRFC transaction ID, under
which this IDoc was sent to the Business Connector, but this
also works for IDocs received via XML document, if the http
POST contained the header field X-TID.)
wm.PartnerMgr.xtn.admin:delete
Deletes one transaction from the Message Store.
Input Parameters
$tid The TID of the transaction
Return values

SAP SE
None.
wm.PartnerMgr.xtn.admin:deleteAll
Deletes the entire Message Store. (Be careful with this...!)
wm.PartnerMgr.xtn.admin:deleteSelection
Deletes the current selection, that was created with wm.PartnerMgr.xtn.admin:list.
Here is the way this should be used: first invoke wm.PartnerMgr.xtn.admin:list with the
inputs "mode=Update Search" and various search criteria. (For example, to delete all
confirmed transactions from supplier42, which were received before 2003-05-26, set the
following inputs:
mode Update Search
upperTime 2003-05-26 00:00:00
senderFilter supplier42
stateFilter Confirmed
) Afterwards invoke wm.PartnerMgr.xtn.admin:deleteSelection.
wm.PartnerMgr.xtn.archive:create
Allows archiving a certain selection of transactions from the Message Store, while the
Business Connector is running. The transaction’s status information and the message body
are put into a zip file and removed from the Message Store. The resulting zip archive can
later be loaded back into the Business Connector (or into another “display” Business
Connector) using the service using the service wm.PartnerMgr.xtn.archive:restore.
Input Parameters
olderThan All transactions older than the given timestamp will be

archived, if they also satisfy the remaining criteria. The
timestamp needs to be given in the usual format defined under
“Settings  Logging  Log Timestamp Format”. (This is the
same format used in the Message Store display.)
ageInDays All transactions that are older than the given number of days
will be archived, if they also satisfy the remaining criteria. Can
be used instead of the olderThan parameter.
sender, receiver, Search filter which further allow to limit the selection of
msgType (optional) transactions to be archived. The following wildcards can be

SAP SE
used: * for an arbitrary number of characters, ? for exactly one

character and ^ for negating the filter. Example: sender=^A*
would archive all transactions, whose sender does not start
with an A.
state (optional) This filter allows selecting only transactions that are in a
certain status.
targetDirectory Specifies the directory, into which the resulting zip archive
(optional) should be saved. Default value:
<sapbc>\packages\WmPartners\pub\mailbox
zipFileName (optional) A name for the resulting zip archive. Default value:
TransactionArchive_yyyyMMdd_HHmmss.zip
deleteFromMessageStor Flag specifying whether the archived transactions should

e actually be deleted from the Message store. If set to false, the
zip archive will be created, but the transactions will not be
deleted. This way you can first test the zip archive for
correctness and completeness, before actually deleting the
transactions (e.g. from the admin UI). But note: if new
transactions arrive in the Message Store in the time between
the zip file is created and the deletion is being performed, then
the same search filter settings may return a different selection
and consequently transactions may be deleted, which are not
yet in the zip archive!
The selection criteria olderThan, sender, receiver, msgType, and state are combined with a
logical AND, i.e. only those transactions are selected, which satisfy all conditions.
Leaving one of these filters empty has the same effect as specifying *. Note:
• This procedure allows archiving transactions while the BC is up and running. But
nevertheless you should be careful about the following in order to avoid
inconsistent data: if a transaction, which is currently being archived, is at the same
time still processed by the Business Connector, then it may happen that an
outdated status is written into the zip archive and that the last few Audit entries
are lost. Therefore, make sure, that the selection of transaction includes only
transactions, which are currently not processed by the BC. This can be achieved
for example by archiving only transactions that are older than a week or already in
status “Confirmed”, or by disabling the corresponding routing rule, so that the BC
can momentarily not receive any additional messages with the same
sender/receiver/msgType combination.
• This service deletes the status information from the files xtn.log and xtn_audit.log
and makes the space available again for future transactions, so that these files at
least no longer grow. But it can’t reduce the size of these files while the BC is up.
This is not bad per se, quite on the contrary: the performance of the Message Store
should be slightly better, if it can reuse already existing memory blocks in the log
files instead of continuously increasing the files in the file system. However, if the
files have grown so large, that their sheer size has become a performance
problem, you should shrink the Message store after archiving or deleting a large
portion of it. See wm.PartnerMgr.xtn.admin:shrinkStore.
Return values

SAP SE
None.
wm.PartnerMgr.xtn.archive:restore
This service reads the specified zip file and loads the transactions it contains back into the
Message Store. The zip file needs to be in the format created by the create service.
Input Parameters
targetDirectory Directory in which the service should look for the zip archive to
(optional) be restored. If none is specified, the service looks in
<sapbc>\packages\WmPartners\pub\mailbox.
zipFileName Name of the zip archive.
deleteZipFile Specifies whether the zip file should be deleted after the
transactions have successfully been imported.
Return values
None.
wm.PartnerMgr.xtn.admin:shrinkStore
Shrinks the two files xtn.log and xtn_audit.log to their current minimum size,
removing space that has formerly been occupied by transactions that have meanwhile been
deleted or archived.
Note: This can only be done, if the BC is currently not processing any transactions!
Input Parameters
None.
Return values
None.
Note: The following administrative Services in wm.PartnerMgr.xtn.admin should not be used by

applications: setViewService, viewAs (are used internally by the Administrator UI).
Transport Services

SAP SE
pub.sap.transport.ALE:InboundProcess
Receives an IDoc and forwards it to the Partner Manager.
Input Parameters
This service requires the following input parameters.
is that, for IDocs version 2 the service looks for IDOC_CONTROL and IDOC_DATA in
IDOC_DATA_REC_40. Alternatively, it accepts an IDoc object in IDoc library format.
$tid Transaction ID (TID).
$action One of the following transaction codes:
Code Meaning
0 Create
1 Execute
2 Rollback
3 Commit
4 Confirm
IDOC_CONTROL Record list (Table) object that contains the control and data
IDOC_DATA tables for the IDoc.
or
IDOC_CONTROL_REC_40 The SDATA field needs to be a record containing the keys

IDOC_DATA_REC_40 and values from the segment table (the name of the
segment table is specified by the SEGNAM field.)
or
iDocList An object of the Java IDoc Library.
Return Values
pub.sap.transport.ALE:OutboundProcess
Sends an IDoc to an SAP server.

SAP SE
It is recommended that you use this service for IDocs rather than invoking
pub.sap.client:createTID and pub.sap.client:invokeTransaction, which performs the same function.
This service does not invoke pub.sap.client:confirmTID.
Input Parameters
This service requires the following input parameters.
is that, for IDocs version 2 the service looks for IDOC_CONTROL and IDOC_DATA in
IDOC_DATA_REC_40. Alternatively, it accepts an IDoc object in IDoc library format.
transportParams A record with the following key/value pair.
server SAP server alias for the SAP server to which you want to
send the IDoc. The alias must match a configured SAP
server alias on the SAP Business Connector Server.
IDOC_CONTROL Record list (Table) object that contains the control and data
IDOC_DATA tables for the IDoc.
or
IDOC_CONTROL_REC_40 The SDATA field is a Values object containing the keys and
IDOC_DATA_REC_40 values form the segment table (the name of the segment
table is specified by the SEGNAM field.)
or
iDocList An object of the Java IDoc Library.
$tid Transaction ID (TID).
$action One of the following transaction codes:
Code Meaning
0 Create
1 Execute
2 Rollback
3 Commit
4 Confirm
Return Values

SAP SE
wm.PartnerMgr.gateway.transport.B2B:InboundProcess
Receives a message from a remote SAP Business Connector Server and forwards it to the
Partner Manager, which determines the Routing Rule to use to route the message based
on the sender, receiver, and message type specified in the input parameters. After
determining the Routing Rule to use, it invokes the Flow Service that processes the
matching Routing Rule.
It is recommended that you use this service as the receiving point when you are connecting two
Business Connectors. The ALE:InboundProcess could also be used, but it has the disadvantage
that it repeats the extraction of the sender/receiver/msgType parameters. These parameters are
already present in the pipeline sent from the originating SAP BC, so they don’t need to be
extracted again.
Input Parameters
This service requires the following input parameters from the Pipeline.
In addition to the parameters specified below, the input parameters must also include the
message to be routed through the Partner Manager. Use a key for the message that the outbound
transport expects.
This Key Must specify…
sender The sender of a message to be routed.
receiver The receiver of the message.

msgType Message type of the message.
$routeOnly Optionally, whether the message is to be only routed or

whether the message is to be routed and recorded in the
Message Store. Specify true if you want the message
routed but not recorded in the Message Store. Specify
false if you want the message both routed and recorded in
the Message Store. If you do not specify this parameter,
the default is false.
$tid Optionally, the transaction ID. If you do not specify a

transaction ID and $routeOnly is false, the Partner
Manager generates a transaction ID for the transaction.
Return Values
Depending on transaction and invoked outbound service.
wm.PartnerMgr.gateway.transport.B2B:OutboundProcess
Invokes a service on a local or remote SAP Business Connector.

SAP SE
If you want to invoke a service on a remote SAP Business Connector Server, the local SAP
Business Connector Server must have an alias defined for the remote server. For more
information about creating aliases for remote SAP Business Connector servers, refer to the SAP
Business Connector Administration Guide.
Input Parameters
This service requires the following input parameters from the pipeline.
$tid Optionally, a transaction ID.

We generally recommend transmitting a Transaction ID to
the partner system for logging and tracing purposes. You
do not need to enter a TID manually when receiving IDocs
from SAP: $tid is set automatically in this case.
serverAlias Identification of the SAP Business

Connector Server on which the
service is to be invoked.
To invoke a service on a remote
server, specify the alias for the remote
server.
The default value is local, which
indicates the local server. Use local to
invoke a service on the local server
that is not password protected.
To invoke a password protected
service on the local server, set up an
alias for the local server, specifying a
username and password that has
access to the password protected
service. Then, specify that alias name.
servicePath Folder name for the service to invoke.
service Name of the service to invoke.
valueScope Optionally, the scope for the session.

This is where you want the Partner
Manager to store the connection to
the remote server. SESSION indicates
the connection is to be saved in your
own session. GLOBAL indicates the
connection is to be saved in a shared
area. Use SESSION when the work
being performed requires state be
maintained.

SAP SE
Return Values
It returns the result of the service that is invoked.
The last service of this folder (wm.PartnerMgr.gateway.transport.B2B:confirmTID) is only used
internally by the gateway manager. Hands off!
wm.PartnerMgr.gateway.transport.EmailTransport:OutboundProcess
Sends a document via an e-mail message to the specified recipients.
This service is intended to be used only by the Partner Manager to route messages via e-mail
messages. If you want to send information via e-mail outside of the Partner Manager, use the
pub.client:smtp service.
Input Parameters
data IData object that contains the outbound document to send

in the e-mail message. The IData object contains the
following fields:

content An object that represents the content
of the document. It must be one of the
following data types: String, byte[],
InputStream.
filename Optional. Specifies a filename to be
used for the mail attachment. If
omitted, the attachment name will be
either <tid>.xml, if a $tid is
present in the pipeline, or
ATT<n>.txt with an increasing
number n, otherwise.
transportParams Record containing the e-mail configuration parameters (all
are of type String):

mailhost Host name of the SMTP server which
is to be used to relay the email
message.
from E-mail address to use for the sender of

the e-mail message.
to E-mail address of the recipient of the

document. To specify multiple
recipients, separate each e-mail
address with a comma.

SAP SE
contenttype Content type of the document (e.g.

MIME type).
cc E-mail address of each recipient to

receive a complimentary copy. To
specify multiple recipients, separate
each e-mail address with a comma.
bcc E-mail address of each recipient to

receive a blind complimentary copy. To
specify multiple recipients, separate
each e-mail address with a comma.
subject Subject for the e-mail message.
body Optional. Note for the receiver.
Return Values
None.
wm.PartnerMgr.gateway.transport.FTPTransport:OutboundProcess
FTPs a document to an FTP server. The name of the document on the FTP server will
have the format, ftpfile<n>.data, where n is an increasing number that the FTP
transport process generates.
In case there is a $tid in the pipeline, the filename is <tid>.xml. You can overwrite
these default names if required.
This service is intended to be used only by the Partner Manager to route messages via FTP. If
you want to send information via FTP outside of the Partner Manager, use the pub.client:ftp
service.
Input Parameters
data An IData object that contains the outbound document to
FTP. It contains the following fields:

content An object that represents the content of
the document. It must be one of the
following data types: String, byte[],
InputStream.
transportParams Record containing the FTP configuration parameters (all
are of type String):

SAP SE
serverhost FTP host name where you want the

document sent.
serverport Port number on which the remote FTP

server (serverhost) listens for incoming
requests. The default number is 21.
username Valid FTP username that the SAP

Business Connector Server must
supply to connect to the remote FTP
server.
password Corresponding password of the FTP

user (username) that the SAP
Business Connector Server must
supply to connect to the remote FTP
server.
dirpath Directory path on the target machine

where the message is to be placed.
transfertyp Optional. ‘active’ or ‘passive’. This

e determines whether the client or the
server is supposed to open the data
connection.
remotefile With this parameter you can overwrite

the default name used for the
transferred file.
timeout Time (measured in seconds) to wait for

a response from the ftp server before
timing out and aborting the request.
Default is to wait forever.
Return Values
returncode Return code from the FTP server. This is a three-digit
number that indicates the status of the FTP put command.
returnmsg Corresponding return message for the return code.
logmsg Log message of the entire FTP session.

SAP SE
pub.sap.transport.RFC:InboundProcess
Receives an inbound RFC or an RFC-XML document that is to be routed through the
Partner Manager. To route an RFC through the Partner Manager, the SAP System must
add the SBCHEADER table to the RFC.
Input Parameters
This service requires one of following input parameters from the Values object.
SBCHEADER Array of records (key/value). For information about what to
include in the array of records, refer to “The SBCHEADER
Table” on page 4-25.
sbcHeader IData object representing the key/value pairs in the

SBCHEADER table. For information about what to include
in the array of records, refer to “The SBCHEADER Table”
on page 4-25.
$tid Optionally, a transaction ID.

If you want to process the RFC call asynchronously using
tRFC, specify the transaction ID. If you would like to
perform a synchronous RFC call, do not specify this
parameter.
$action Optionally, the transaction state. Specify one of the

following codes:
Code Gives the transaction this state:
0 CREATED
1 EXECUTED
2 COMMITTED
3 ROLLEDBACK
4 CONFIRMED
Return Values
pub.sap.transport.RFC:OutboundProcess
Invokes an RFC on an SAP server. This service can handle both RFC and tRFC calls.
Input Parameters

SAP SE


server The SAP server alias for the SAP server
on which invoke the RFC. The alias must
match a configured SAP server alias on
the SAP Business Connector Server.
$tid Transaction ID (optional).

If you want to process the RFC call asynchronously using
tRFC, specify the transaction ID. If you would like to
perform a synchronous RFC call, do not specify this
parameter.
$action Transaction state (optional). Specify one of the following

codes:
Code Gives the transaction this state:
0 CREATED
1 EXECUTED
2 COMMITTED
3 ROLLEDBACK
4 CONFIRMED
$rfcname (optional) function module that should be called
Return Values
There are no specific return values, but the pipeline contains the result of the invoked
function module (if the call was made synchronously).
pub.sap.transport.XML:InboundProcess
Can be called (e.g. using HTTP post) with arbitrary XML documents to pass them on to
the Partner Manager.
Input Parameters

SAP SE
node Document object that can be generated by calling

stringToDocument and is automatically generated when
posting an XML document via HTTP using the content-type
text/xml.
Return Values
No specific values in the pipeline.
pub.sap.transport.XML:OutboundProcess
Use this service to post an XML document to a specified URL.
The XML transport is mainly used for posting XML documents to external Web servers.
If you want to communicate with another Business Connector or webMethods'
Integration Server, you can use the B2B transport.
Input Parameters
This service requires the following input parameters from the pipeline.
xmldata(optional) An XML document as string, only used if
transportParams/xmlType is "Arbitrary XML".
transportParams A record with the following key/value pairs.

url The URL to which to post the
document.

SAP SE
xmlType The XML dialect to use.

Specify Values-XML if you want the
XML in webMethods native XML
format.
Specify SAP-XML if you want the XML
in a format that is compliant with the
SAP XML specification. For an IDoc,
IDoc-XML is used; for an RFC, RFC-
XML (XRFC) is used. Note that the
IDoc must be available as input to this
service.
Specify bXML to post BAPI-XML with
a BizTalk envelope. (Can be used
when routing BAPI calls.)
Specify Arbitrary XML to post any XML
document.
Specify SOAP XRFC to use XRFC
(RFC-XML) with a SOAP envelope (of
version higher than SOAP 1.1).
useTextXml Flag that overwrites the content-type

(opitonal) of bXML, XRFC and IDoc-XML to
text/xml, if set to true.
useUTF8 Flag that allows forcing the XML

(optional) rendering engines to use UTF-8 as
encoding for the resulting documents.
httpUser Optionally, the username to supply for

a username/password authentication
challenge.
httpPassword Optionally, the password to supply

along with httpUser for a
username/password authentication
challenge.
useBapi ON or OFF. If set to ON, the pipeline

is encoded using bXML for Business
Objects.
object The name of the business object, to

which the call should be mapped.
bapi The name of the BAPI method, to

which the call should be mapped
$tid Optionally, the transaction ID. Specify a transaction ID if the

document should be sent as a transaction. The TID is
transmitted in an additional HTTP header named X-TID.

SAP SE
Return Values
The return values depend on the document that is posted. The return value is an IData
object representation of the response to the posted document.
pub.sap.transport.BAPI:InboundProcess
When posting bXML documents representing a BAPI of a Business Object to this
service, it will take care of passing the document to the Partner Manager.
Input Parameters
$object Name of the business object that is represented in the

pipeline.
$bapi Name of the BAPI that is represented in the pipeline.
$sbcHeader Record containing the key/value pairs with routing information.

Will be generated by the bXML parser.
Return Values
A pipeline representing the response or an exception of the executed BAPI.
pub.sap.transport.BAPI:OutboundProcess
Executes a BAPI in an SAP system. This transport service can handle both asynchronous
and synchronous execution of a BAPI.
Input Parameters
$tid (optional) See $tid for RFC:OutboundProcess.
$action (optional) See $action for RFC:OutboundProcess.
transportParams A record with the following key/value pairs.

SAP SE
server The SAP server alias for the SAP server on which to execute
the BAPI. The alias must match a configured SAP server alias
on the SAP Business Connector Server.
mode Allows restricting the way how the BAPI can be invoked:
• no restrictions: Will be executed as the client
requested
• synchronous only: Only synchronous call is allowed.
If client passes a $tid (indicating an asynchronous
call) an exception is thrown.
• asynchronous only: Only asynchronous call is
allowed. If client does not pass a $tid (indicating a
synchronous call) an exception is thrown.
Return Values
A pipeline representing the response or an exception of the executed BAPI.
XSLT Services
pub.sap.xslt.transformation:XSLTransformation
This service takes as input an XML source, a stylesheet name, and optional global parameters to be
used in the transformation. The service executes the necessary transformations based on the XSL
stylesheet and produces the output plus any output parameters.
Input
xmlString - String - The XML string to transform. Required if xmlRecord is not
provided. If both are provided, then only xmlRecord is
used.
xmlRecord -Record - The XML in a record structure. Required if xmlString is not

provided.
stylesheetFilename - The stylesheet to use in the transformation. This can also

String - include a path (i.e.
packages/XSLTSamples/pub/xdocs/xslt/Date.xsl).
inputParameters - Record Global parameters to be passed into the XSL

- transformation.

SAP SE
inRecordDefName - Name of the record definition to use for parsing the source
String - XML record (xmlRecord). Parsing of the source XML
record is done according to this definition. Exceptions are
thrown when a required field is defined in the record
definition but not found in the source or when the source
XML record contains more than one root. Fields that are
found in the source XML, but not defined in the record
definition are ignored; no error is indicated.
outRecordDefName - Name of the record definition to use when building the

String - resulting record structure. If this is not provided, then the
result will be in the form of a string. An error condition
occurs when a required field is not found in the
corresponding result of the XSL transformation. Fields that
are found in the result, but not defined in the record
definition are ignored.
Output
transformedXmlString - String representing the transformed XML. This is the
String - default result from this transformation. However, if the
input parameter outRecordDefName is provided, then this
will be null.
transformedXmlRecord - Record containing the transformed XML. To get this as

Record - the result, the input parameter outRecordDefName must
be provided.
outputParameters - Record structure containing values retrieved during the

Record - transformation.
Note: in order to have access to output parameters, the style sheet must first declare a
namespace for an object that will hold the parameters and define a global parameter
(output) for that object. This object is automatically created by the XSLT engine, so it is
not necessary to explicitly instantiate it and pass it in as an input parameter. To declare
the namespace, in the <xsl:stylesheet ...> instruction, include the following:
xmlns:Output="java://com.sap.xslt.extension.Output"
For XSLT 1.1-compliant stylesheets, the <xsl:script> tag should also be used:
<xsl:script implements-prefix="Output" language="java"
src="java://com.sap.xslt.extension.Output"/>
Note: to declare a parameter as global, include the following top-level instruction:

<xsl:param name="output"/>
The object's put method can then be used to store desired output values. When the
XSLT processing is completed, the values stored in this object are put into the

SAP SE
outputParameters record structure.
pub.sap.xslt.transformation:clearTemplatesCache
This service removes all style sheets from the style sheets cache.
Input
None
Output
message
pub.sap.xslt.transformation:removeCachedTemplate
This service removes style sheet 'stylesheet' from the style sheets cache.
Input
stylesheet The stylesheet used in a transformation. This can also include a

path (i.e. packages/XSLTSamples/pub/xdocs/xslt/Date.xsl)."
Output
message
Demo Services
sap.demo:handleIDocXMLPost
Submit an IDoc-XML document to the ALE InboundProcess on a Business Connector.
Input Parameters
xmlData (String) The XML string of the IDoc document to be sent.
Required.
Return Values
None.

SAP SE
sap.demo:handleRfcXMLPost
Submit an RFC-XML to an SAP system to invoke the associated RFC function.
Input Parameters
serverName (String) The SAP server alias of the target SAP system. Required.
xmlData (String) The XML string of the RFC-XML document. Required.
$envelope bXML or RFC-XML, document type used for the post.
Return Values
xmlData XML document representing the response of the function
module.
Note: This service is designed only for executing function modules that do not require
an explicit commit.
sap.demo:handlebXMLPost
Submits a bXML to an SAP system to invoke the associated BAPI.
Input Parameters
serverName The SAP server alias for the SAP server on which execute
the BAPI. The alias must match a configured SAP server
alias on the SAP Business Connector.
xmlData (String) XML document representing a BAPI request in bXML.
mode Allows to choose the way how the BAPI will be invoked:
• sync: synchronous execution
• async: asynchronous execution
• routing: apply routing info contained in the
document
Return Values
xmlData XML document representing the response of the BAPI.
Note: This service is designed only for executing function modules that do not require
an explicit commit.

SAP SE
sap.demo:writeSAPXMLFile
This service will convert RFCs or IDocs coming from an SAP system to SAP-XML
(IDoc-XML or RFC-XML) and write the result to an output file in the 'sap/pub' directory.
To call it create a routing rule, choose the B2B transport and specify this service or call it
directly.
Input Parameters
None.
Return Values
None.
sap.demo:invokeBAPIReturningbXML
This service is used within handlebXMLPost.
Miscellaneous Services
wm.PartnerMgr.gateway.runtime:confirmTID
This service can be used in scenarios, where an external client sends XML messages to
the Business Connector, which are forwarded to an SAP system via tRFC, and where the
client wants to achieve "transactional behavior" from end to end. The call sequence in this
case should be as follows:
1. The client creates a 24 digit GUID (or calls pub.sap.client:createTID to obtain one
from the SAP system).
2. The client sends the document to one of the InboundProcesses (for example an
IDoc-XML to the pub.sap.transport.ALE:InboundProcess) and passes the TID along
in the header field "X-TID: <tid>". The Routing Rule, which processes this
message in the Business Connector, should have the "Forward ConfirmTID
Event" flag set to true.
3. If and only if the client receives a return code 200 from the SAP BC in step 2, it
calls wm.PartnerMgr.gateway.runtime:confirmTID like this:
GET /invoke/wm.PartnerMgr.gateway.runtime/confirmTID?$tid=<tid> HTTP/1.0
This achieves two things: The state in the Business Connector's Message Store is
set to "Confirmed", and the entry in the receiving SAP system's tRFC check table
(ARFCRSTATE) is cleaned up. This may be important for tRFC performance, if
the SAP system receives large numbers of documents.
4. If the client receives an error return code in step 2 or no response at all, it may
later resubmit the same document (using the same TID) without needing to fear

SAP SE
duplicate processing. Then, after one of the subsequent tries has finally
succeeded, the TID can be confirmed as described in step 3.
Note: if the document is sent another time after the confirmTID has already been executed,
this will lead to a duplicate document! Thus, confirmTID should be called only, if the
client knows, that the document has been processed ok, and if the client will therefore
never resubmit this document again.
Input Parameters
$tid The transaction ID
wm.PartnerMgr.xtn.Sweeper:sweepTRX
This service can be used to clean up the Message Store. For example, set it up in the
Scheduler with the following inputs:
Input Parameters
onState The state of the transactions to be deleted.
elapsedTime Time in minutes that the transactions have already been in
the given state.
maxTrxCount Maximum number of transactions to be deleted in one
execution of the Service.
IDoc Java API

See <SAPBC>\server\packages\SAP\pub\doc\api\index.html.

SAP SE
Appendix E List of deprecated services

In the following, all services and specifications are listed that have been replaced by new ones as of
release 4.6. The old services have been deleted as of release 4.7.
Previous New service/specification

wm.PartnerMgr.gateway.transport.A pub.sap.transport.ALE:InboundProcess
LE:InboundProcess
wm.PartnerMgr.gateway.transport.A pub.sap.transport.ALE:OutboundProcess
LE:OutboundProcess
wm.PartnerMgr.gateway.transport.A pub.sap.transport.ALE:getRoutingInfo_Defau
LE:getRoutingInfo_Default lt
wm.PartnerMgr.gateway.transport.R pub.sap.transport.RFC:InboundProcess
FC:InboundProcess
wm.PartnerMgr.gateway.transport.R pub.sap.transport.RFC:OutboundProcess
FC:OutboundProcess
wm.PartnerMgr.gateway.transport.B pub.sap.transport.BAPI:InboundProcess
API:InboundProcess
wm.PartnerMgr.gateway.transport.B pub.sap.transport.BAPI:OutboundProcess
API:OutboundProcess
wm.PartnerMgr.gateway.transport.X pub.sap.transport.XML:InboundProcess
ML:InboundProcess
wm.PartnerMgr.gateway.transport.X pub.sap.transport.XML:OutboundProcess
ML:OutboundProcess
Previous New service/specification Previous
wm.PartnerMgr.gateway.transport.X pub.sap.transport.XML:xmlRoutingInfo
ML:xmlRoutingInfo
sap:confirmTID pub.sap.client:confirmTID
sap:connect pub.sap.client:connect
sap:createTID pub.sap.client:createTID
sap.admin:getAttributes pub.sap.client:getAttributes
sap.admin:getFunctionInterface pub.sap.client:getFunctionInterface
sap.admin:getStructureDefinition pub.sap.client:getStructureDefinition
sap:invoke pub.sap.client:invoke
sap:indirectCall pub.sap.client:invokeTransaction
sap:lockSession pub.sap.client:lockSession
SAP Business Connector E-61

SAP SE
sap:releaseSession pub.sap.client:releaseSession
sap.bapi:encode pub.sap.bapi:encode
sap.bapi:decode pub.sap.bapi:decode
sap.bapi.Browser:createTemplate pub.sap.bapi:createTemplate
sap.bapi.transaction:rollback pub.sap.bapi:rollback
sap.bapi.transaction:commit pub.sap.bapi:commit
sap.rfc:encode pub.sap.rfc:encode
sap.rfc:decode pub.sap.rfc:decode
sap.rfc:createTemplate pub.sap.rfc:createTemplate
sap.idoc:encode pub.sap.idoc:encode
sap.idoc:decode pub.sap.idoc:decode
sap.idoc:encodeSDATA pub.sap.idoc:encodeSDATA
sap.idoc:decodeSDATA pub.sap.idoc:decodeSDATA
sap.idoc:transformFlatToHierarchy pub.sap.idoc:transformFlatToHierarchy
sap.idoc:transformHierarchyToFlat pub.sap.idoc:transformHierarchyToFlat
sap.idoc.routing:inbound pub.sap.idoc.routing:inbound
sap.idoc.routing:inboundDefault pub.sap.idoc.routing:inboundDefault
sap.idoc.routing:outbound pub.sap.idoc.routing:outbound
sap.idoc.routing:outboundDefault pub.sap.idoc.routing:outboundDefault
sap.idoc.routing:registerService pub.sap.idoc.routing:registerService
sap.idoc.routing:unregisterService pub.sap.idoc.routing:unregisterService
Previous New service/specification

sap:OutboundRFC pub.sap.client:invoke or
pub.sap.client:invokeTransaction
(for tRFC)
sap:InboundRFC No replacment
sap:disconnect No longer necessary, because session pools are
used
sap:tablesToRecordLists No longer necessary, because tables can be

handled in flow now natively

INDEX

INDEX
Appendix F INDEX
A
administrative tasks
defining routing rules, 5-9
deleting routing rules, 5-18
displaying routing rules, 5-16
managing transactions in Message Store, 5-21
updating routing rules, 5-17
ALE (R/3 IDoc) transport, 5-13
ALE transport
create logical system, 7-2
B
B2B Service transport, 5-10
BAPI map outbound, 3-17
browser
post IDoc to an SAP system, 7-7
C
cache, DDIC
description, 10-13
removing function modules, 10-16
viewing contents, 10-13
changing routing rules, 5-17
configuration files, A-2
configure inbound (SAP-to-SAP BC), 4-7
connect to an SAP system, 3-12
connection service, D-2
creating
routing rules, basic procedures, 5-9
D
data dictionary cache. See DDIC cache
DDIC cache
description, 10-13
removing function modules, 10-16
viewing contents, 10-13
debugging IDoc mapping, 7-21
defining
routing rules, 5-9
definitions, 2-6, 3-16
deleting
routing rules, 5-18
transactions, 5-25
demo services, D-57
disabling routing rules, 5-18
displaying
routing rules, 5-17
transactions, 5-22
distribution model, 7-4
documentation
related manuals, 1-2
using effectively, 1-2
E
editing routing rules, 5-17
editing the routing service, 5-18
SAP Business Connector 2

INDEX
Email Outbound Service transport, 5-11

updating routing rule flow, 5-20
F
files in SAP package, A-2
Flow Service for routing rule
updating, 5-19
FTP Outbound Service transport, 5-12
updating routing rule flow, 5-20
function module
create, 4-20
example, 4-27
function modules
caching, 10-13
removing from DDIC cache, 10-16
viewing those cached, 10-13
H
how to
delete routing rules, 5-18
disable a routing rule, 5-18
edit routing rules, 5-17
purge the message store periodically, 5-26
view routing rules, 5-17
HTTP POST
IDoc, 7-7
RFC, 3-22
I
IDoc
send to SAP system, 7-7
services, D-17
versions, D-17
XML POST service, D-57
IDOC
mapping to other applications, 7-10
IDoc Java API, 8-2, D-60
L
Listener, 2-6
create, 4-7
test, 4-9, 4-12
lock SAP session, D-3, D-4
log file, A-2
logical system
define, 7-2
M
map inbound RFC, 4-20
MAP operation, in routing service, 5-19
map outbound BAPI, 3-17
map outbound RFC, 3-17
mapping fields from IDOCs, 7-10
Message Store
deleting transactions, 5-25
managing transactions, 5-21
viewing transactions, 5-22
message type value, 5-4
msgType parameter

INDEX
using a wildcard, 5-5
O
ORDERS IDoc, 7-7
ORDRSP IDoc, 7-7
outbound RFC service, D-6, D-12
overview
Partner Manager, 5-2
routing rules, 5-2
P
Partner Manager
deleting transactions in Message Store, 5-25
managing transactions in Message Store, 5-21
overview, 5-2
processing when no routing rule, 5-15
transports, 5-10
viewing transactions in Message Store, 5-22
partner profile, 7-4
post IDoc from browser, 7-7
POST IDoc-XML, 7-5
POST RFC-XML, 3-22
post-processing service
overview of, 5-7
pre-processing services
description, 5-7
specifying, 5-10
product retrieval sample, 4-21
R
raw post
IDoc-XML, 7-5
RFC-XML, 3-23
receiver parameter
receiver value, 5-4
record definitions, creating for IDOCS, 7-13
request RFC, 3-15
restorePipeline, 7-21
RFC
send to SAP system, 3-22
XML
template, D-15
XML POST service, D-57, D-58
RFC destination
create, 4-2
RFC Listener
create, 4-7
test, 4-9, 4-12
RFC map outbound, 3-17
RFC request, 3-15
routing rule
dynamic routing, 4-25
routing rules
ALE (R/3 IDoc) transport, 5-13
B2B Service transport, 5-10
completing, 5-16
defining, 5-9
deleting, 5-18
disabling, 5-18

INDEX
editing, 5-17
Email Outbound Service transport, 5-11
Flow Service that processes, 5-6
FTP Outbound Service transport, 5-12
match precedence, 5-5
message type value, 5-4
naming Flow Service that processes, 5-9
overview of, 5-2
post-processing service, 5-7
pre-processing service, 5-7
receiver value, 5-4
sender value, 5-4
specifying transports, 5-10
transports, 5-8
updating Flow Service that processes, 5-19
updating the routing service, 5-18
viewing, 5-17
when not defined, 5-15
XML transport, 5-13, 5-14
routing service
editing, 5-18
MAP operation, 5-19
S
SAP invoke service, D-5
SAP package directory files, A-2
SAP server
test connection, 3-12
savePipeline, 7-21
SBCHEADER table, 4-25
SDATA conversion, D-17
sender parameter
sender value, 5-4
services
demo, D-57
IDoc, D-17
services, creating from BAPIs, 3-16
settings, A-2
structure definitions
caching, 10-13
viewing those cached, 10-13
T
template
RFC-XML, D-15
terminology, 2-6, 3-16
TID confirmation service, D-7
TID creation service, D-7
transactions
deleting, 5-25
managing, 5-21
viewing, 5-22
transactions list, 5-24
transports
ALE (R/3 IDoc), 5-13
B2B Service, 5-10
description, 5-8
Email Outbound Service, 5-11
FTP Outbound Service, 5-12

INDEX
specifying, 5-10
XML), 5-13, 5-14
tRFC
log, A-2
using, 8-4, 8-8
U
updating
Flow Service that processes routing rule, 5-19
updating routing rules, 5-17
V
Values format-to-XML conversion, D-14, D-26, D-27, D-28, D-29, D-53, D-54
viewing
routing rules, 5-17
transactions, 5-22
W
Web browser
post IDoc to an SAP system, 7-7
wildcards
definition of, 5-5
using as routing criteria, 5-5
X
XML
convert to IDoc, D-25
XML transport, 5-13, 5-14
XRFC Services, D-14

SBC SAPAdapterGuide 481

Uploaded by

Copyright:

Available Formats

SBC SAPAdapterGuide 481

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SBC SAPAdapterGuide 481

Uploaded by

Copyright:

Available Formats

SAP Business Connector

SAP Adapter Guide

SAP® SE  Dietmar-Hopp-Allee  D-69190 Walldorf

SAP Business Connector ii

Type Style Description

Document Title Cross-references to other documentation.

NAME Names of elements in the SAP System. These include program

A note. Notes contain important information, e.g. exceptions or

An example. Examples illustrate complex procedures or the syntax

Hints and Tips.

SAP Business Connector iii

Chapter 1: Introduction ............................................................................................1-1

SAP Business Connector iv

Starting to Browse ............................................................................................3-23

SAP Business Connector v

Components of a Routing Rule ...........................................................................5-3

SAP Business Connector vi

SAP Business Connector vii

Java Client Code ................................................................................................9-2

SAP Business Connector viii

pub.sap.rfc:decode .......................................................................................... D-15

SAP Business Connector ix

wm.PartnerMgr.xtn.admin:get .......................................................................... D-38

SAP Business Connector x

Appendix E List of deprecated services ................................................................. E-61

SAP Business Connector xi

Welcome! .............................................................................. 1-2

SAP Business Connector

Refer to this book… For…

This guide is only available, when the SAP BC Developer is installed.

This guide is only available, when the SAP BC Developer is installed.

SAP Business Connector 1-2

Refer to this book… For…

This guide is only available, when the SAP BC Developer is installed.

RFC-XML Specification In depth information about the RFC-XML specifications

SAP Business Connector 1-3

Chapter 2: Product Overview

What is the SAP Business Connector?........................................ 2-2

SAP Business Connector 2-1

What is the SAP Business Connector?

SAP Business Connector 2-2

Complete SAP System Integration

Integrating SAP Systems over the Internet

Routing IDocs, RFCs and BAPIs

SAP Business Connector 2-3

Support for IDoc- and RFC-XML

Support of BizTalk XML envelopes for BAPI and RFC calls

Support of Unified Error Handling of BAPIs and RFCs on XML Level

SAP Business Connector 2-4

Built-in BAPI Tools

SAP Business Connector 2-5

Architecture and Components

SAP Business Connector 2-6

IDoc (Intermediate EDI-like SAP business document.

SAP Business Connector 2-7

Architecture and Components

SAP Server SAP BC Server

RFCs and BAPIs SAP BC Services

Invoking Business Logic

You can quickly and easily The SAP BC Server