Interface Documentation BC-CON - Archive...System represents the RFC server and the calling program represents the RFC client. If R/3 calls the functions in an external system it is

1

SAP BC-CON

SAPconnect - The Interface in the R/3 System for E-Mail/Fax Systems

Version 01.02.B

R/3 4.5A

17 Feb 1999

2

Changes to SAP BC-CON SAPconnect documentation V 01.01.C:

1) New address type 'PAG' for Paging (see page 15)

2) Minor general changes to administrative part (CSP/ICC)

CONTENTS

1 Introduction............................................................................................................................................... 3

2 The RFC Interface..................................................................................................................................... 5

2.1 RFC SDK ............................................................................................................................................... 5

2.2. Using RFC in SAPconnect ............................................................................................................... 7

2.3 Implementation Procedure ..........................................................................................................10

3 SAPconnect - RFC Functions in Overview ........................................................................................10

3.1 Status Transfer Process ...................................................................................................................12

3.2 Object Data.....................................................................................................................................13

3.3 List of Receivers................................................................................................................................15

4 RFC Description ......................................................................................................................................17

4.1 SX_OBJECT_RECEIVE.......................................................................................................................17

4.2 SX_OBJECT_STATUS_RECEIVE.........................................................................................................28

A. Appendix

A.1. Status Code List

3

1 Introduction

Standard Communication Channel

SAPconnect has been developed as a successor for SAPcomm with the aim ofproviding a standard communication channel for all communication systems,including integration with the SAP Internet Mail Gateway and a connectionbetween different R/3 Systems.Using RFC technology, SAPconnect allows you to access many othercommunication systems (e.g. fax servers, X.400 MTA, Internet mail nodes, etc.)directly from R/3.

The interface is certifiable for Fax (BC-CON Fax and Email - SAPconnect) sinceR/3 3.1G and for Paging (BC-PAG Paging) starting with R/3 4.5A.. Moreinformation about the certification process can be found on SAP web pageshttp://www.sap.com/csp . Interface documentation are stored athttp://www.sap.com/csp/scenarios .

Object

Any messaging object can be sent from or received by the R/3 System. Objectscan be e.g. in the form of an Internet mail or an SAPoffice mail sent to one ormore users or they can be for use by a certain program. Objects are structuredin the same way as SAPoffice documents; i.e. they contain a document (socalled “main document”) with one, several or no attachments. The data in anobject can be in different formats (e.g. TIFF, ASCII, PostScript, PDF etc.)according to which formats are supported by the external communicationsystem and R/3. One of the most important aims of SAPconnect is to monitor theconversion of formats for objects which are to be sent from the R/3 System.

Connection to Communication Interfaces

SAPconnect allows R/3 to be connected directly to mail or communicationsystems via its API (RFC interface).

Scheduling

Additional SAPconnect functions can be identified under the key words‘Scheduling’ and ‘Routing’. Scheduling includes the forwarding of objects to thecommunication nodes according to certain time criteria and also allows anobject to be resent if necessary.

Routing

SAPconnect includes an outbound routing function which enables messages tobe routed via various communication systems to ensure an improvement in loaddistribution and a reduction in costs.

SAPconnect does not support a store-and-forward function between several R/3Systems in a system group. Each client of each R/3 System must be connectedindividually to the appropriate communication nodes and vice versa.

4

Address format

The SAPconnect RFC interface supports all address formats supported by R/3:SMTP, X.400, Fax, Paging, and SAPoffice (R/3-to-R/3 mail).

More details can be found in the description of function moduleSX_OBJECT_RECEIVE (transaction SE37, Goto -> Documentation -> Functionmodule doc.(F9)).

5

2 The RFC Interface

The SAPconnect API interface uses the standard R/3 RFC (Remote Function Call) technologywhich is also used by many other interfaces within the R/3 System itself (e.g. BAPI).

This chapter describes the data and data transfer. (A general description of RFC can be found inthe online documentation under BC-Basic Components, Basis Services/Communication Interfaceentitled "Remote Communications" (BC-SRV-RC) in the chapters ‘The RFC API' and 'RFCProgramming in ABAP/4’.)

This chapter includes an illustration of the process of calling the RFC interface for SAPconnectand which infrastructure should be available. Finally, you will learn how to use the SAPconnectinterface itself.

2.1 RFC SDK

Before using the SAPconnect RFC interface, at least the R/3 Software development kit (SDK) onthe R/3 Presentation CD is required and, in later stages, an R/3 System for testing.With the aid of the “Complementary Software Program” provided by SAP for this purpose, theirpartners can receive:

• CSP Developer Package (SDK/Remote)includes Software Development Kit updates for new SAP Releases and remote access to testand preview systems.

• An R/3 Test&Demo License after successful certification, or

• A complete R/3 System

You can find more information and the names of contact persons on the World Wide Web underhttp://www.sap.com/csp or by searching for “Complementary Software Program” from SAP’sWWW homepage. The most important documents are those entitled “Questions and Answers”,“Contacts” and “Partner Types”.

The CSP Developer Package comprises the RFC SDK with DLLs, libraries and header files for alloperating system platforms supported by R/3. This allows you to include the RFC interface in yourown programs. The CD also contains the SAP Gateway installation possibility. A standalone SAPGateway is required for loopback tests without any R/3 System.The description of these components can be found in the following R/3 online documentationwhich is included in the CSP Developer Package.

1. R/3 online documentation about RFC:R/3 Library > BC - Basis Components > Basis Services / Communication Interfaces (BC-SRV) >Remote Communications (BC-SRV-RC) > Remote Communications > The RFC API,alternatively as WinHelp file in the desktop SDK help subdirectory after installation from CD.

2. R/3 online documentation about the SAP Gateway:R/3 Library > BC - Basis Components > Basis Services / Communication Interfaces (BC-SRV) >BC - SAP Communication - Configuration,alternatively as README file on Presentation CD.

3. SAP Technical Developers Conference in May 1996 (CD):X:\DESKTOP\RFC_API.PDF - this is internal documentation about RFC.

4. SAP Partner Academy offers BAPI - Overview course TACA90 (check web page:http://www.sap.com/csp -> Services for Partners).

6

5. SAP Partner Academy offers SAPconnect Customizing course TACON1 (check web page:http://www.sap.com/csp -> Services for Partners).

The following sections are based on the documentation mentioned above.

7

2.2. Using RFC in SAPconnect

RFC Server and Client

SAPconnect defines two function modules:SX_OBJECT_RECEIVE is used for transferring objects (E-mail, fax, IDocs, etc.) andSX_OBJECT_STATUS_RECEIVE is used for transferring status information aboutobjects.

If these functions are called in R/3, from the point of view of the external system,the R/3 is dealing with received, i.e. inbound, objects. In such a case, the R/3System represents the RFC server and the calling program represents the RFCclient. If R/3 calls the functions in an external system it is dealing with sent, i.e.outbound, objects. In such a case, the R/3 System becomes the RFC client andthe called program becomes the RFC server.

Synchronous RFC

Although data in the R/3 System is updated, synchronous RFC is used instead oftransactional or asynchronous RFC. Any possible problems (duplicates in thereceiving system) must be detected in the receiving system (in the case ofSAPconnect, the corresponding R/3 System). In SAPoffice, the message ID,receiver and sender are analyzed for this purpose. The use of the synchronousRFC also ensures that status information for each receiver can be returned to thecaller after the processing of the RFC (synchronous status). In addition, statusvalues can also be sent asynchronously (later) via SX_OBJECT_STATUS_RECEIVE,e.g. for read confirmations.

RFC Server Registration(see Figure 1)

The RFC server running on workstation/front-end platform can be called by theR/3 System in two ways:

a) Triggered start (via application server, SAPGUIand explicit computer ID entry), or

b) Via registration with the SAP Gateway

Due to the fact that a communication system (e.g. fax server) usually representsa process which is constantly running (e.g. NT Service or UNIX Daemon), does notuse SAPGUI and is not forced to run on the SAP Gateway, the registration variantis used. While the system is being booted, the RFC server part of thecommunication system informs the SAP Gateway of the identifier under which itshould be addressed. This identifier must also be defined in the correspondingRFC destination in the R/3 System.

A standalone R/3 gateway can be installed on the partner hardware platformfor better performance, please check OSS note 85254 (4.0x/4.5A) or 137478 (4.5B)for more details.

8

RFC Client: Logging on to the R/3 System

An RFC client process must log on to an R/3 System under an SAP username (usertype CPIC). In case that inbound documents should be forwarded to multipleclients of either one single or multiple R/3 systems, the external communicationsystem must log on to each R/3 client individually.

The sending and receiving of information can also be tested without an R/3System (using ‘loopback’). The gateway can be configured in such a way thatthe workstation can be addressed as a server (see Figure 2).

Figure 1:

Working in Parallel

The RFC DLL is multi-threading capable. On the RFC server side, it is possible to letseveral RFC server processes or threads register under the same ProgramId to theSAP Gateway. The SAP Gateway distributes RFC calls as a dispatcher toavailable RFC server processes/threads. On the RFC client side, it is possible, in

R/3 DB Server

R/3 ApplicationServer (AS)

R/3 ASRFC Server

R/3 AS

R/3 AS withMessage Server

SAP Gateway

RFC Client: Network/CPIC connection

RFC call to R/3

Figure 1: RFC Server/RFC Client and SAP Gateway Overview (Inbound direction)

9

parallel, to call the SAPconnect function modules in R/3. In such a case, eachRFC client process or thread must log on to R/3. Logging on to the SAP MessageServer is beneficial in this situation because the message server can execute anautomatic load balancing process which distributes parallel RFC calls to theapplication server with the smallest system load.

Repeated Calls When Errors Occur

If a temporary error in calling the RFC module is recognized by the RFC client(e.g. RFC error COMMUNICATION_FAILURE (connection problems) andSYSTEM_FAILURE (computer problems)) while messages or status messages arebeing transferred to the R/3 System, the client should have access to a repeatcall mechanism which makes a predefined number of attempts to send thedata and then creates a list of the data which could not be transferred.

Figure 2:

R/3 DB Server

R/3 ApplicationServer (AS)

R/3 ASRFC Server

R/3 AS

SAP Gateway

RFC Client

: Network/CPIC connection

2. RFC call to communication system

Figure 2: RFC Server/RFC Client and SAP Gateway Overview (Outbound direction)

RFC Client

1. RFC registration(permanent RFCconnection) 2.

3. RFC loopbackcall

Partner Program

10

2.3 Implementation Procedure

Installation

1. From the Presentation CD, you should install at least the RFC SDK and the SAPGateway. As an introduction, you read the README file located in the rootdirectory of the CD.

2. From an R/3 System sample code for the RFC modules SX_OBJECT_RECEIVEand SX_OBJECT_STATUS_RECEIVE (R/3 Release 3.1 or higher) can begenerated via transaction SE37 (Function Builder - Initial Screen): Utilities ->RFC Interface -> Generate.

Compile this code, taking into account the RFC library, DLL files and header files.Please ensure that the DLL is accessible at runtime.

Using the sample programs as a basis, you can attach your own communicationsolutions.

Note for Windows NT

If you implement MFC, you should not use the RfcDispatch ( ) function in theserver program. Instead, you should use RfcGetName( ) and execute thedispatching manually.

3 SAPconnect - RFC Functions in Overview

Using the RFC Modules

Data exchange between SAPconnect and an external communication systemtakes place via synchronous RFC. When sending data using RFC, you shouldproceed as follows (see Figure 3):

1. An object to be sent is generated using the SAPoffice user interface or anapplication and is then transferred to SAPoffice. SAPconnect accesses thisobject and transfers it via RFC call from SX_OBJECT_RECEIVE to one or morespecified nodes.

2. Each node processes the object and sends back a synchronous statusmessage informing the sender whether the transmission request was rejected,executed successfully or to be accepted at a later (asynchronous) time.

3. At any point in the future, using RFC call SX_OBJECT_STATUS_RECEIVE, eachnode can release additional status information about this object to thesending system (asynchronous status message).

The receiving process is a mirror image of the sending process.

11

Synchronous Status

In the case of synchronous status confirmation, status code fields and status textfields are determined in the table RECEIVERS for each receiver by the functionmodule SX_OBJECT_RECEIVE which was called.

As a result, the status information always refers to the send process which iscurrently being processed.

The status codes and the contents of the additional information fields MSGV1 toMSGV4 are described in the appendix A.

Asynchronous Status

Asynchronous status confirmation allows status information to be transferred at alater date (e.g. confirmation that the object has been read) by calling thefunction module SX_OBJECT_STATUS_RECEIVE in the sender node. The tableRECEIVERS can be used to determine the status code for each receiver and thestatus text fields. The object reference is created from the field REPLY_TO.

Figure 3: Synchronous Status / Asynchronous Status (Outbound direction)

Application

SAPoffice

SAPconnect

SX_OBJECT_STATUS_RECEIVE

Address

managem

ent

SX_OBJECT_RECEIVE SEND STATUS

Partner Program

R/3

1.Synchronous Status

2. 3.Asynchronous Status

12

Apart from the object-oriented status information, it is also possible to use thefunction module SX_OBJECT_STATUS_RECEIVE to transfer status information aboutthe condition of the node.

3.1 Status Transfer Process

The transfer of status information via RFC takes place via the status code andadditional status text fields for each receiver.

In the case of synchronous status, the reference to the message sent is given bythe import parameter, i.e. RECEIVE_INFO. However, in the case of asynchronousstatus, the reference must be created by the REPLY_TO field in the RECEIVE_INFOstructure.

The following diagram illustrates the relevant fields with example values:

Figure 4: Status Information Transfer

Node A Node B

Call SX_OBJECT_RECEIVERECEIVE_INFO-SENDER=ARECEIVE_INFO-COMMID=4711RECEIVE_IINFO-REPLY_TO=SPACERECEIVERS-RECEIVER=BRECEIVERS-RETRN_CODE=0

Return SX_OBJECT_RECEIVERECEIVERS-RECEIVER=BRECEIVERS-RETRN_CODE=701

Call SX_OBJECT_STATUS_RECEIVERECEIVE_INFO-SENDER=ARECEIVE_INFO-COMMID=5812RECEIVE_IINFO-REPLY_TO=4711RECEIVERS-RECEIVER=BRECEIVERS-RETRN_CODE=703

e.g. R/3e.g. mailcomponents

13

3.2 Object Data

Tables

The object data of the main documents and the attachments in the tablesCONTENTS_TXT for text data and CONTENTS_BIN for binary data is transferredfrom the sender node by calling SX_OBJECT_RECEIVE.The table PACKING_LIST describes the division of data within these tables.

PACKING_LIST Table

Information about the main document and the attachments is transferred to thistable.

It is important that the main document is always contained in the first line oftable PACKING_LIST and possible attachments from the second line onwards.

Field TRANSF_BIN is used to determine whether the data from the maindocument or an attachment are contained in table CONTENTS_TXT or in tableCONTENTS_BIN. Fields BODY_START and BODY_NUM specify the first and numberof lines of data (in the case of binary content, field DOC_SIZE must be used todetermine the exact end of data).

In addition, information relating to name, type, length and language can befound in table PACKING_LIST.

CONTENTS_TXT and CONTENTS_BIN Tables

The division of data in text form and binary data in different tables takes placebecause of the required character set conversion: data in table CONTENTS_TXTis subject to a character set conversion during the RFC call, but data in tableCONTENTS_BIN is transferred without conversion. The RFC automaticallyrecognizes which character set conversion is to be executed.

The relationship between the various parameters in table PACKING_LIST can beillustrated using the following diagrams:

14

2nd line

3rd line

Attachments (2-n)Main document

PACKING_LIST: 1st line

RAW

TXT

DOC

nth line

in PACKING_LIST

Figure 5: Object Structure

PACKING_LIST

CONTENTS_TXT

CONTENTS_BIN

123

4::20

Start, end

1

20

RFC characterset conversion

No characterset conversion

TRANS_BIN =BODY_START = 1BODY_NUM = 3



Figure 6: PACKING_LIST Parameters (required fields)

15

3.3 List of Receivers

RECEIVERS Table

Table RECEIVERS contains all information about the receivers of an object,including the receiver-oriented attributes (e.g. express, blind copy etc.). Theentries in this table are required for the distribution path.

Field COPY_LIST specifies whether a receiver should actually receive the object(see figure 7) or is only included in the list of receivers (see figure 8).

The examples given in figures 7-8 illustrate how different receivers can receive anobject via various communication nodes. The Internet receiver is indicated as aCC: receiver, but X.400 receivers and fax receivers have no such CC: indicator.

X.400

FaxSMTP

R/3

e.g.X.400 Interface X.400

MTA

MS Exchange

Node 1

Node 2

Fax Connector

Internet Connector

Receiver 1

Receiver 3

Receiver 2

Figure 7: Object routed via 2 different nodes and sent simultaneously to various receivers

16

X.400

Fax

Internet

Sent to receiver 1on 29 July 1996

Sent to receivers 2 and 3on 30 July 1996

Figure 8: Object sent to various receivers at different times. Field COPY_LIST in table RECEIVERS isselected. The object is not sent to a receiver who has already received it. In such cases,the receiver is still included in the receiver list.

The following graphic illustrates how the entries in table RECEIVERS appear in the scenario fromfigure 7 (calling MS Exchange) and figure 8 (call on 30 July).

Receiver = [email protected]_TYP = InternetCOPY_LIST = SPACECOPY = XVISNAME = John BellSTATUSCODE = 0

Receiver = C = DE;A = DBP; P = SAP; S = XYZADR_TYP = X.400COPY_LIST = XCOPY = SPACEVISNAME = Carol FinnSTATUSCODE = 0

Receiver =00141789ADR_TYP = FAXCOPY_LIST = SPACECOPY = XVISNAME = Brenda SmithSTATUSCODE = 0

Figure 9: Extract from table RECEIVERS for node 2

17

4 RFC Description

Implementation Notes

1. The indicators ‘Required’, ‘Optional’, ‘Obsolete’ and ‘Internal’ specifywhether an parameter must be given, may be given, should not be used (in thecase of a field from an earlier API1 interface which is no longer supported) or isonly used internally.

2. Flags and Boolean variables contain ‘X’ if they are set and ‘ ‘ (emptycharacter) if they are not set.

3. More information about ABAP-specific data format descriptions (e.g. CHAR,DATS etc.) can be found in the SDK documentation.

4. The initialization of the CHAR fields takes place using empty characters(spaces). In contrast to C strings, they do not end with a hex zero because hexzero may not be used.

5. The initialization of the NUMC fields takes place using a character display ofthe numbers, e.g. “000000000000000”. No hex zero endings are used in this caseeither.

6. Date and time fields are initialized in the same way as CHAR fields.

7. If the RFC server or client is implemented in C or C++, users must ensure that allseven tables are entered when RfcGetData( ) or RfcCall Receive( ) is called. It isimportant that an ItCreate ( ) is called for each table on the RFC client side,even when the table itself is not used.

4.1 SX_OBJECT_RECEIVE

Functionality

This function module allows the transfer of an object (E-mail, fax, IDoc, etc.)including any attachments between an R/3 System and a communicationsystem. When the object has arrived in the target system, it is sent to all receiversentered in the table RECEIVERS when the function module is called. From theSAPoffice perspective, the owner becomes the sender of the object and thecreator is the user who has executed the function module.

There is normally a particular user responsible for handling e-mails.

In the case of inbound objects, the function module is called by anothercommunication component (e.g. another R/3 System or a fax system) via RFC.When sending an object, the function module is called by SAPconnect via RFCin the external communication component.

18

4.1.1 IMPORT Parameters

RECEIVE_INFO

This structure must contain information about the sender of the object (address, message ID,creation time and date, and send time). In addition, the creation date for the object andthe send date can be entered.

COMM_ID (CHAR 964) (Required)

The message ID of the transferred object which should be uniquelygenerated by the sender. This ID is given in replies in the fieldRECEIVE_INFO-REPLY_TO in cases of asynchronous status messages.IDs generated by R/3 are always 23 bytes in length, whereas externalsenders can transfer a maximum of 964 bytes (X.400).

SENDER (CHAR 1215) (Required)

Address of the sender of an object.The following entry types can be used (notation: <fieldvalue>(CHARno.) ):

- Fax number in the form <number>(30). For outbound messages,R/3 provides the receiver with a fax number which can bedialed (taking into account the international dialing code). Thenumber of the R/3 user entered in address management is givenas the sender.

For inbound messages, fax numbers can, in principle, be given inany format. The receiver numbers must, however, correspond tothe entry in address management, taking into account theautomatic number changes in R/3. The fax number of the sendershould be a number which can be dialed directly (for any reply).

- Internet address according to RFC822 in the form<local>@<domain>(241).

- X.400 address in the form C=<country>(3);A=<adm.domain>(16);P=<priv.domain>(16);O=<org.name>(64);OU1=<org.unit1>(32);OU2=<org.unit2>(32); OU3=<org.unit3>(32);OU4=<org.unit4>(32);S=<lastname>(40);G=<ffrstname>(16);I=<initials>(1);Q=<generation>(3);DDA1=<1.DDAType>(8);DDA1V=<1.DDAValue>(128);DDA2=<2.DDAType>(8);DDA2V=<2.DDAValue>(128); DDA3=<3.DDAType>(8);DDA3V=<3.DDAValue>(128); DDA4=<4.DDAType>(8);DDA4V=<4.DDAValue>(128),e.g. C=DE;A=DBP;P=SAP;S=MILLER;G=FRED

- Pager address in the form <service>(4):<number>(30),e.g. SMS:062279191919

19

ADR_TYPE (CHAR 4) (Required)

Type of address in RECEIVE_INFO_SENDER.

The following values are allowed:- ‘FAX’: fax number- ‘INT’ : Internet address (SMTP)- ‘X40’ : X.400 address- ‘PAG’: pager address

REPLY_TO (CHAR 964) (Optional)

If this field is selected, the sent object is seen as a reply to the objectindicated by the ID entered. In this case, a correspondence history isautomatically created or continued.

SEND_DATE (DATS - Date field YYYYMMDD - saved as CHAR 8) (Optional)

Date on which the object was sent.

SEND_TIME (TIMS - time field hhmmss - saved as CHAR 6) (Optional)

Time at which the object was sent.

CREATE_DATE DATS - Date field YYYYMMDD - saved as CHAR 8) (Optional)

Date on which the object was created.

CREAT_TIME (TIMS - Time field hhmmss - saved as CHAR 6) (Optional)

Time at which the object was created.

SND_VINAME (CHAR 30) (Optional)

SND_VINAME is the real name of the sender,compare with valid SMTP address:"Frank Hoffmann" <[email protected]>,where “Frank Hoffmann” is the SND_VINAME value and<[email protected]> the address.

DOCUMENT_DATA

This structure must contain the attributes of the object to be sent. These include the nameand type of the object, the expiry date, receiver priority and planned send time. The tablePACKING_LIST contains identical fields for the main document. When completing thesefields, please remember that the entries in DOCUMENT_DATA should correspond exactly withthose in PACKING_LIST.

OBJ_NAME (CHAR 12) (Optional)

Name of the object stored/to be stored in SAPoffice.

20

OBJ_DESCR (CHAR 50) (Optional)

Short description of the contents of the object (reference line).

OBJ_LANGU (LANG 1) (Internal)

SAP-internal key for the language of the object.

OBJ_SORT (CHAR 10) (Optional)

Sort field for the object. Users can search for the term entered here inSAPoffice attribute searches.

OBJ_EXPDAT (DATS - Date field YYYYMMDD - saved as CHAR 8) (Internal)

Used internally.

SENSITIVITY (CHAR 1) (Optional)

Object confidentiality.A personal object can have the following levels of confidentiality:

- ‘O’: standard confidentiality- ‘F’: functional, can be forwarded functionally- ‘P’: confidential, cannot be viewed by substitute

OBJ_PRIO (CHAR 1) (Optional)

The sender can assign a priority level to the object (0 - high, 2 - low).This value determines the speed at which the message is processedby the communication system. It is possible for high priority messagesto overtake those with low priority.

NO_CHANGE (CHAR 1) (Optional)

If this field is selected (contains ‘X’), the object may only be changedby the author.

PRIORITY (CHAR 1) (Optional)

Priority of an object, ranging from 0 (high) to 9 (low). The priority levelof the object is also displayed in the inbox.

EXPIRY_DAT (DATS - Date field YYYYMMDD - saved as CHAR 8) (Optional)

Expiry date of the object after it is received.

PROC_TYPE (CHAR 1) (Internal)

Used internally.

PROC_NAME (CHAR 30) (Internal)

Used internally.

21

PROC_SYST (CHAR 10) (Internal)

Used internally.

PROC_CLINT (CLNT 3) (Internal)

Used internally.

SKIP_SCREN (CHAR 1) (Internal)

Used internally.

TO_DO_OUT (CHAR 1) (Internal)

Used internally.

FREE_DEL (CHAR 1) (Internal)

Used internally.

DOC_SIZE (CHAR 12) (Required for binary main body parts)

Total size of the first object (=main body part) in bytes. The number ofbytes determines the end of the last line of the object inCONTEXT_BIN.(DOC_SIZE MOD 255 = No. bytes last line).

STA_TIME (TIMS - Time field hhmmss - saved as CHAR 6) (Optional)

Earliest time at which the document should have reached receiver.

STA_DATE (DATS - Date field YYYYMMDD - saved as CHAR 8) (Optional)

Earliest date on which the document should have reached receiver.

END_TIME TIMS - Time field hhmmss - saved as CHAR 6) (Optional)

Latest time at which the document should have reached receiver.

END_DATE (DATS - Date field YYYYMMDD - saved as CHAR 8) (Optional)

Latest date on which the document should have reached receiver.

Note: The fields STA_* and END_* can be used to enter a time period for the sending of objects.Users can therefore take advantage of cheaper connection rates at night, for example.

SYSTEM_DATA

This structure contains information about calling the RFC.

NODE (CHAR 6) (Internal)

Used internally.

22

VERSION (CHAR 4) (Required)

Field displaying the RFC version. The contents are structured in theform xxyy. For the current version, the field should contain the value0101. An increase in xx signifies an incompatible change, a change inyy signifies a compatible change. If the first number is larger than thecurrent version number in R/3, an exception is triggered. If the secondnumber is larger than the current version number in R/3, a trace entryis triggered.

4.1.2 TABLE Parameter

RECEIVERS

The receivers of the object must be entered in this table. The table must contain at least oneentry.

RECEIVER (CHAR 1215) (Required)

Name of the receiver. Enter as for RECEIVE_INFO-SENDER.

ADR_TYP (CHAR 4) (Required)

Enter as for RECEIVE_INFO-ADR_TYP.

COPY_LIST (CHAR 1) (Required)

Specifies whether the object should be sent to receiver or whetherthe receiver should only be included in the receiver list, havingalready been sent the object.‘X’ : Object must not given to the receiver‘ ’ : Object is to be given to the receiver

EXPRESS (CHAR 1) (Optional)

If this field contains an ‘X’, the object is sent with the attribute Express.If the receiver is a SAPoffice user who is logged on, a messageappears on screen informing the receiver that an express object hasbeen received.

COPY (CHAR 1) (Optional)

If this field contains an ‘X’, the object is sent with the attribute Copy.

BLIND_COPY (CHAR 1) (Optional)

If this field contains an ‘X’, the object is sent with the attribute Blindcopy. SAPoffice users cannot print or forward these messages.

NO_FORWARD (CHAR 1) (Optional)

If this field contains an ‘X’, the object cannot be forwarded by anSAPoffice user.

23

NO_PRINT (CHAR 1) (Optional)

If this field contains an ‘X’, the object cannot be printed by anSAPoffice user.

TO_ANSWER (CHAR 1) (Optional)

If this field contains an ‘X’ and the receiver is an SAPoffice user, thereceiver must send a reply before the object can be removed fromthe SAPoffice inbox.

TO_DO_EXPL (CHAR 1) (Optional)

If this field contains an ‘X’ and the receiver is an SAPoffice user, thereceiver must set the object to ‘done’ before the object can beremoved from the SAPoffice inbox.

TO_DO_GRP (CHAR 1) (Optional)

‘To Do’ group of receiver. A number in the range 1-9 can be enteredto identify the group of receivers to be sent the object with the To Doattribute. When one of the receivers in this group sets the object to‘done’, the object disappears from the inbox of all the otherreceivers. If the value ‘0’ is entered, the To Do attribute is not set.

COM_TYPE (CHAR 6) (Obsolete)

This field is not used.

LFDNR (CHAR 3) (Obsolete)


FAX (CHAR 30) (Obsolete)


COUNTRY (CHAR 3) (Obsolete)


SPOOL_ID (CHAR 5) (Obsolete)


NOTIF_DEL (CHAR 1) (Optional)

If this field contains an ‘X’, the sender receives confirmation as soonas the object is delivered to the receiver. The sender also receives amessage if the object could not be delivered.

This message, however, is supported by only very few mail systems,e.g. X.400 and SAP. This function is under development for Internetmail.

24

NOTIF_READ CHAR 1) (Optional)

If this field contains an ‘X’, the sender receives a message as soon asthe object has been viewed by the receiver. This message, however,is supported by only very few mail systems, e.g. X.400 and SAP. Thisfunction is under development for Internet mail.

NOTIF_NDEL (CHAR 1) (Optional)

If this field contains an ‘X’, the sender receives a message if theobject could not be sent to the receiver. This information can becalled from the receiver list. This message, however, is supported byonly very few mail systems, e.g. X.400 and SAP. This function is underdevelopment for Internet mail.

SAP_BODY (CHAR 1) (Optional)

If this field contains an ‘X’, the SAP-specific files are sent with theobject in an external data division. This option should only be usedwhen the target system is an SAP system. The object is stored in theinbox as a true SAPoffice object, i.e. all object attributes are retained(e.g. SAPscript object formatting).

REC_DATE (DATS - Date field YYYYMMDD - saved as CHAR 8) (Optional)

Date on which correspondence object was received.

RETRN_CODE (CHAR 4) (Internal)

Used Internally.

VISNAME (CHAR 30) (Optional)

Real name of receiver. Enter as for RECEIVE_INFO-SND_VINAME

PROCTIME (TIMS - Time field hhmmss - saved as CHAR 6) (Optional)

Time at which the object was transmitted.

PROCDATE (DATS – Date field YYYYMMDD - saved as CHAR 8) (Optional)

Date on which the object was transmitted.

TNEF (CHAR 1) (Optional)

If this field contains an ‘X’, it is known that the receiver understandsTNEF coding (see Microsoft TNEF coding in the WINMAIL.DATattachment).

MIME (CHAR 1) (Optional)

If this field contains an ‘X’, it is known that the receiver understandsMIME coding (see Internet Mail RFC 1521).

25

UUENCODE (CHAR 1) (Optional)

If this field contains an ‘X’, it is known that the receiver understandsUUENCODE coding.

CODE (CHAR 3) (Required for return)

This value returns the status code for synchronous or asynchronousstatus notifications. (Compare with status code list in Appendix A.1.)

MSGV1 (CHAR 50) (Optional)

Variable with which a special explanatory status text can be givenwith a status code.







26

PACKING_LIST

This table contains information about how to distribute the data in tables CONTENTS_BIN andCONTENTS_TXT between the object and its attachments. The first line refers to the maindocument and each of the following lines refers to an attachment. Certain information aboutthe main document (e.g. DOC_SIZE) can be found in PACKING_LIST and in DOCUMENT_DATA).

TRANSF_BIN (CHAR 1) (Required)

If this field contains an ‘X’, the table entry indicates an object storedin binary format. The contents of the relevant object are located inthe table CONTENTS_BIN. If this field does not contain an entry, thecontents of the object are located in the table CONTENTS_TXT in theappropriate character set. If necessary, the RFC mechanism executesa character set conversion from the calling system to the calledsystem.

HEAD_START (NUMC 15) (Internal)

Used internally.

HEAD_NUM (NUMC 15) (Internal)

Used internally.

BODY_START (NUMC 15) (Required)

Contains the start line of the table dependent on flag TRANSF_BIN. Thecontents of the object are stored from the first line onwards.

BODY_NUM (NUMC 15) (Required)

Contains the number of lines of the relevant table entry which areoccupied by the object contents. The lines concerned are assigned ina block and specified in a unique manner suing the entry inBODY_START.

DOC_TYPE (CHAR 3) (Optional)

Object type. This corresponds to the file extension type, e.g. for aWinWord file, the extension type is *.DOC or one of the following SAPtypes:

'BIN' : unstructured binary data'GRA' : binary graphic data'IDC' : text data (SAP IDoc format)'OTF' : text data (SAP OTF format)'PDF' : text data (Portable Document Format)'PS' : text data (Postscript format)'RAW' : text data'RTF' : binary data (Rich Text Format)'SCR' : text data (SAPscript format)'TIF' : binary data (fax multipage TIFF)

27

OBJ_NAME (CHAR 12) (Optional)

Name of the object in SAPoffice as entered when creating themessage.

OBJ_DESCR (CHAR 50) (Optional)

Title (short description) of the object.

OBJ_LANGU (LANG 1) (Optional)

SAP-internal key for the language of the object. Possible values arecontained in system table T002.

DOC_SIZE (CHAR 12) (Required for binary body parts)

Total size of the object in bytes. The number of bytes determines theend of the last line of the object in CONTEXT_BIN.(DOC_SIZE MOD 255 = No. bytes last line).

MESS_TYPE (CHAR 4)

This field specifies whether the object data is located outside R/3 andtable CONTENTS_TXT contains only a path reference.

There are currently two possible values:Space = data in CONTENTS_TXT or CONTENTS_BIN‘P’ = file path in URL format in CONTENTS_TXT

ISO_LANGU (CHAR 2) (Optional)

Two-character ISO code for the language of the object.

CONTENTS_BIN

This table must contain a summary of the contents of objects saved as binary objects.

LINE (RAW 255)

Object contents are transferred and saved in binary format.

CONTENTS_TXT

This table must contain a summary of the contents of objects saved as ASCII objects.

LINE (CHAR 255)

Object contents are transferred and saved in text format or charactercode translation.

OBJECT_HEADER

Used Internally.

28

OBJECT_PARA

Used Internally.

OBJECT_PARB

Used Internally.

4.1.3 Exceptions

Function module SX_OBJECT_RECEIVE may only end with an exception if the object could not bedelivered to any receivers. Therefore, an Exception should always mean that an error hasoccurred which affects the whole message or message attributes for all addresses.

ERR_NODE_UNKNOWN (Internal)

The node of the communications component to whichthe message should be forwarded could not be foundby the R/3 System from which the message was sent.

ERR_INVALID_VERSION The version number entered has an invalid format.

ERR_REC_NOT_SPECIFIED Table RECEIVERS has not been completed.

ERR_INCOMPATIBLE_VERSION The version numbers of the RFC used (first twocharacters) are different from the RFC version numberin R/3.

ERR_PAC_NOT_SPECIFIED Table PACKING_LIST has not been completed.

ERR_INTERNAL Internal error or problem with the enqueue server.

ERR_AUTHORITY Authority check failed (S_RFC Authorization Object ismissing in authorization profile of RFC user in SAPSystem).

4.2 SX_OBJECT_STATUS_RECEIVE

Note: Only the fields which are different from the fields in the function moduleSX_OBJECT_RECEIVE are described in this section.

Functionality

This function module allows the return of status information about objects whichhave been sent. The status information is saved in SAPoffice.

29

4.2.1 TABLES Parameters

RECEIVERS

Contains the receivers of the object to which the status message refers. One item of statusinformation can be entered for each receiver.

RECEIVE_INFO

COMM_ID (CHAR 964) (Required)

New message ID of the status message.

SENDER (CHAR 1215) (Required)

Contains the sender address for the object to which the statusmessage refers (see Figure 4), NOT the sender of the status message.

REPLY_TO (CHAR 964) (Required)

Message ID of the sent object to which the status message refers.

PACKING_LIST

Not yet supported.

CONTENTS_TXT

Not yet supported.

CONTENTS_BIN

Not yet supported.

4.2.2 EXCEPTIONS

ERR_ORIG_NOT_FOUND The object to which the status information refers couldnot be found.

ERR_INVALID_SYSTEM The system of the object to which the statusinformation refers could not be found.

ERR_REC_NOT_SPECIFIED The function module was called without entering areceiver.

ERR_INTERNAL Internal error or problem with the enqueue server.

ERR_INVALID_VERSION Format of version number is invalid.

ERR_INVALID_SNDADDR Sender address is invalid.

30

ERR_INVALID_RECADDR At least one recipient address is invalid.

ERR_INCOMPATIBLE_VERSION Different version numbers (first two digits).

ERR_NODE_UNKNOWN Specified node is invalid in SYSTEM_DATA

ERR_PAC_NOT_SPECIFIED PACKING_LIST not completed

ERR_AUTHORITY Authority check failed (S_RFC Authorization Object ismissing in authorization profile of RFC user in SAPSystem).

31

A. APPENDIX

A1 STATUS CODE LIST *

Description Remarks

V1 V2 V3 V4

700 *** Information Codes ***

701 Delivered successfully to & Should cause a delivery report

Receiver Not used yet Not used yet Additionalinformation

702 No information about delivery to & Should not cause a status message


703 Message read by & Should cause a read notification


704 Message processed by & Should cause a read notification


705 Message deleted by & Should cause a read notification


706 Message not read by & Should cause a non-read notification


707 Message not processed by & Should cause a non-read notification


708 Receiver forbids read/processed notification Should not cause a status message


709 Receiver rejects message Should cause a non-read notification


32

710 Message transferred to node & Internal information

Node Not used yet Not used yet Additionalinformation

711 Message transferred from node & to communication system Internal information


712 General message from node &. See long text Internal information

Node Additionalinformation

Additionalinformation


713 Transmission costs for message & Internal information

Message Costs Currency Additionalinformation

714 Node & started Administrator information


715 Node & finished Administrator information


716 Status sent successfully Administrator information

Message Not used yet Not used yet Additionalinformation

717 Node not responsible for receiver & Administrator information

Receiver Node Not used yet Additionalinformation

33

750 *** Warning Codes ***

751 Message cannot currently be transferred to node & due to RFCerror

Internal error

Node RFCdestination

Not used yet Additionalinformation

752 Node & reports partial system error, throughput decreased Administrator information


753 Status cannot currently be transferred to node & due to RFC error Internal error


800 *** Error Codes ***

801 Status cannot be sent Should cause a non-delivery notification

Node Message ID Not used yet Additionalinformation

802 No delivery to & because receiver not found Should cause a non-delivery notification


803 No delivery to & because message has expired Should cause a non-delivery notification


804 No delivery to & because of invalid transfer parameters Should cause a non-delivery notification


805 No delivery to & because of too many receivers Should cause a non-delivery notification

Receiver No. ofreceivers


806 No delivery to & because receiver address is invalid Should cause a non-delivery notification

Address Address type Not used yet Additionalinformation

34

807 No delivery to & because receiver is no longer valid Should cause a non-delivery notification


808 No delivery to & because no route found Should cause a non-delivery notification


809 No delivery to & because receiver cannot be contacted at present Should cause a non-delivery notification


810 No delivery to & because max. number of send attempts reached Should cause a non-delivery notification

Receiver No. of sendattempts


811 No delivery to & because part of message cannot be sent Should cause a non-delivery notification


812 No delivery to &, reason: see long text Should cause a non-delivery notification

Receiver Node Additionalinformation


813 No delivery to & because sender address is invalid Should cause a non-delivery notification

Address Address type Error no. Additionalinformation

814 No delivery because sender address type (&) is invalid Should cause a non-delivery notification

Type ofsenderaddress

Error no. Not used yet Additionalinformation

815 No delivery because reference & not readable Should cause a non-delivery notification

Reference Node Types Additionalinformation

816 Message cannot be transferred to node & due to RFC error Internal error, leads to non-delivery notification inR/3

Node RFCdestination


817 Message cannot be processed in R/3, reason: see long text Internal error, leads to non-delivery notification inR/3

Info text Info text Info text Info text

35

818 Message cannot be processed in node &, reason: see long text Internal error, leads to non-delivery notification inR/3

Node Info text Info text Info text

819 Message cannot be processed in node & because receiver isinvalid

Internal error, leads to non-delivery notification inR/3

Node Receiver Not used yet Additionalinformation

820 Message cannot be processed in node & because message cannotbe encoded



821 Message cannot be processed in node & because parameterscannot be converted


Node Error no. Not used yet Additionalinformation

822 Message in node & cannot be transferred to communicationsystem



823 Node & reports system error, system stopped Administrator information


824 Message cannot be processed in node & because service notavailable


Node Address type Not used yet Additionalinformation

825 Message cannot be processed because table & is not complete Administrator information

Table Not used yet Not used yet Not used yet

826 Message cannot be processed because no route exists from & to&

Administrator information

Sender Receiver Type Additionalinformation

827 Message cannot be processed because node & is not known Internal error

Node Not used yet Not used yet Not used yet

36

829 Internal error: & & & & Internal error

Info text Info text Info text Info text

830 Message cannot be processed in node & because of Releaseincompatibility

Node RFC version Additionalinformation


Internal error

* Variables ‘&’ are replaced consecutively by the values of V1,V2,V3,V4.

V1 corresponds to field MSGV1 in table RECEIVERS




Documents

Interface Documentation BC-CON - Archive...System represents the RFC server and the calling program represents the RFC client. If R/3 calls the functions in an external system it is