Implementation Guide for FI-CA Information Container

Contents
1

Overview ........................................................................................................................ 2
1.1
Usage .................................................................................................................... 2
1.2
Software component .............................................................................................. 2
1.3
Availability .............................................................................................................. 2
1.4
Example of Business Process ................................................................................ 2
Functionality of Information Container ............................................................................. 3
2.1
Framework for categories ....................................................................................... 3
2.2
Creation of entries .................................................................................................. 3
2.3
Sending out entries ................................................................................................ 4
2.4
Displaying Information Container entries ................................................................ 5
2.5
Set back send status .............................................................................................. 5
2.6
Events.................................................................................................................... 5
2.6.1 Add data to store (3701) ..................................................................................... 5
2.6.2 Add data to send (3702) ..................................................................................... 6
2.6.3 Send via RFC (3703).......................................................................................... 6
2.6.4 Send via File (3704) ........................................................................................... 7
2.7
Archiving ................................................................................................................ 8
2.7.1 Archiving Object ................................................................................................. 8
2.7.2 Reports .............................................................................................................. 8
Customizing ................................................................................................................... 9
3.1
Definition of Information Container Categories........................................................ 9
3.2
Customizing of Information Container Categories ................................................... 9
Definition of structures .................................................................................................. 10
4.1
Data of process .................................................................................................... 10
4.2
Data to store ........................................................................................................ 10
4.3
Data to send ........................................................................................................ 10
Implementation of Interface .......................................................................................... 11
5.1
Method IF_FKK_INFCO_TYPE~CHECK_REQUIREMENTS ................................ 11
5.2
Method IF_FKK_INFCO_TYPE~GET_DATA_STORE .......................................... 11
5.3
Method IF_FKK_INFCO_TYPE~GET_DATA_SEND ............................................ 12
5.4
Method IF_FKK_INFCO_TYPE~SEND_VIA_XI .................................................... 13
5.5
Method IF_FKK_INFCO_TYPE~SEND_VIA_WSRM (from EhP5 on) ................... 14
Creation of entries ........................................................................................................ 15
6.1
Method Constructor.............................................................................................. 15
6.2
Method STORE_SINGLE ..................................................................................... 15
6.3
Method SAVE_ALL .............................................................................................. 16
6.4
Method CLEAR_ALL ............................................................................................ 16
Test scenario................................................................................................................ 17
7.1
Test scenario XI ................................................................................................... 17
7.1.1 Inbound XI message ........................................................................................ 17
7.1.2 Proxy implementation of Inbound XI Message .................................................. 17
7.2
Test scenario RFC ............................................................................................... 17
7.3
Test scenario File................................................................................................. 17
Appendix ...................................................................................................................... 18
8.1
Transactions ........................................................................................................ 18
8.2
Tables.................................................................................................................. 18
8.3
Packages ............................................................................................................. 18

Page 1 of 18

Implementation Guide for FI-CA Information Container

1 Overview
1.1 Usage
The Information Container is designed for outgoing messages to external systems.
In the case of XI messages the Information Container should be used for bulk notifications.

1.2 Software component

The Information Container is located in software component FI-CA.

1.3 Availability
The framework of the FI-CA Information Container is available with ERP 6.0, EhP2.

1.4 Example of Business Process

An external system sends a collection or disbursement process to the FI-CA system. FI-CA
posts a document. After the posting, the FI-CA processes are doing their work and maybe the
former systems want to know about one of these.
For example, the former system wants to know if after the payment a bank return occurs.
In this case the so called information container category for the bank return 0001 should be
activated. If a bank return then occurs, an entry in the information container will be written
with the relevant return data.
After that, a mass activity sends the bank return data back to the former system.

Page 2 of 18

Implementation Guide for FI-CA Information Container

2 Functionality of Information Container

The following topics were important for the design of the information container:
In FI-CA we have mass data => sending out of messages in packages
Unlimited data should be stored/sent => data is stored in XML structure

2.1 Framework for categories

The idea is that the different categories have to do as little work as possible.
If you want to use the information container for your process, you have to do the following:
1. Think of a name for your information container category
4 characters
The category has to begin with the application (e.g. V for Insurance). For
FI-CA this does not have to be done. A customer category has to begin
with Z.
2. Definition of structures (see separate chapter)
3. Implementation of Interface (see separate chapter)
4. Create Customizing (see separate chapter)
5. Function module/method for the creation of entries (see separate chapter)
6. Call the function module/method for the creation of entries from your application

2.2 Creation of entries

The framework provides an interface that the categories have to implement.
The process also has to call the same methods of the framework class to create entries.
How this should be done is described in a later chapter.
Here you see an overview of what happens:

A short description of the picture (you dont have to understand this at this point of time):
The process is your application. Within this application you want to create an entry in the
Information Container.

Page 3 of 18

Implementation Guide for FI-CA Information Container

The Information Container Type/Category means the implementation of the interface

IF_FKK_INFCO_TYPE.
The following steps are processed, when a new entry should be created:
1. First you create an instance of class CL_FKK_INFCO_STORE.
2. The framework does some checks (e.g. if the category exists) and gets the
Customizing of the category.
3. Then you call the method STORE_SINGLE. With this method you give the process
data to the framework.
4. The framework calls the interface method CHECK_REQUIREMENTS of your
category. If the method determines that the requirements are not fulfilled, then no
entry will be created.
5. The framework calls the interface method GET_DATA_STORE. This method returns
the data which should be stored on the database for this entry.
6. The framework calls the exit 3701. In this exit the customer (and/or the industries) can
fill their own data.
7. The framework creates the data of the new entry/entries and stores them in the
memory.
8. Optional: The method STORE_SINGLE can be called again from the process.
9. At the end the process calls the method SAVE_ALL.
10. The framework updates the database

2.3 Sending out entries

For sending out the Information Container entries, a mass activity is available (transaction
FPINFCO1).
Here you see an overview what happens:

The Information Container Type/Category means the implementation of the interface

IF_FKK_INFCO_TYPE.
How the data should be sent out can be defined by the customer in Customizing. There are 4
possibilities:
XI
RFC
File
WS-RM (from EhP5 on)

Page 4 of 18

Implementation Guide for FI-CA Information Container

The following steps are processed within the mass activity:

1. Selection of the data (parallelization object is the business partner)
2. Grouping of the data:
Packages are built for every:
Information Container Category
Sending Type
Receiver
Package size:
XI and WS-RM: 1 to XI limit of the mass activity run
RFC: 1 to 50
File: 1 to database limit of the mass activity run
3. The mass activity calls the interface method GET_DATA_SEND. This method returns
the data which should be sent out for the package data.
4. The mass activity calls the exit 3702, where the customer (and/or the industries) can
enhance the data to be sent out
5. The mass activity sends out the data:
XI: In this case the interface method SEND_VIA_XI is called. This method
calls the proxy of the corresponding XI message
RFC: Exit 3703 is called. The customer has to implement this exit, if he wants
to send out via RFC, because only he knows the destination.
File: Exit 3704 is called, where the customer has to implement the structure
of the file.
WS-RM: In this case the interface method SEND_VIA_WSRM is called. This
method calls the proxy of the corresponding WS-RM message
6. The mass activity updates the Information Container tables with the sending data.

2.4 Displaying Information Container entries

The information container entries that are created and sent out can be displayed using the
online transaction FPINFCO2.

2.5 Set back send status

If you want to resend data (for test purposes), you can set back the sending information of
entries. You can do this with transaction FPINFCO3.

2.6 Events
2.6.1 Add data to store (3701)
Interface:
FUNCTION FKK_SAMPLE_3701.
*"-----------------------------------------------------------------*"*"Lokale Schnittstelle:
*" IMPORTING
*"
REFERENCE(IS_DATA_ALL) TYPE ANY
*"
REFERENCE(IV_INFCOTYPE) TYPE INFCOTYPE_KK
*" EXPORTING
*"
REFERENCE(ET_RECEIVERS) TYPE FKKINFCO_RECEIVER_T
*"
REFERENCE(EX_DO_NOT_STORE) TYPE XFELD
*" CHANGING
*"
REFERENCE(CS_DATA_STORE) TYPE ANY
*"
REFERENCE(CV_EXPIRY_DAYS) TYPE INFCOSENDEXPIRYDAYS_KK OPTIONAL
*"-----------------------------------------------------------------IS_DATA_ALL: Structure with data of process
IV_INFCOTYPE: Information container category

Page 5 of 18

Implementation Guide for FI-CA Information Container

ET_RECEIVERS: Table of receivers of the data. With this parameter, you can define
the recipient to whom the data of the information container entries is sent. If several
recipients are specified, the same data is sent to the different recipients. The package
creation within the mass activity considers the recipient and creates different send
packages for each recipient
EX_DO_NOT_STORE: With this flag you can return that no new information
container entry should be created.
CS_DATA_STORE: Here the customer can fill the data, which he wants to store, in
the CI-Include. The industries can also fill the SI includes.
CV_EXPIRY_DAYS: With this parameter you can change the number of days after
which data is no longer sent by the mass activity. In the standard, the value is set to
100 days.
This exit is called after the framework has filled the data to store. The customer can enhance
the data to store CS_DATA_STORE with his data.
The exit is marked so that additional functions are allowed. Therefore the industries can fill
their data to store in the SI includes and the customers can fill their CI include.
With this exit the receivers can also be set. If the customer wants to send out the data to
several receivers, then he can fill the table ET_RECEIVERS at that point in time.
If the customer (or the industry) wants to create an information container entry depending on
other data, then he can set the flag EX_DO_NOT_STORE, if no entry should be created for
the current data.
If the data is not sent out via the mass activity FPINFCO1, the customer can set a date after
which the data should not be sent out anymore. In the standard this is set to 100 days.

2.6.2 Add data to send (3702)

Interface:
FUNCTION FKK_SAMPLE_3702.
*"-----------------------------------------------------------------*"*"Lokale Schnittstelle:
*" IMPORTING
*"
REFERENCE(IT_DFKKINFCO) TYPE DFKKINFCO_T
*"
REFERENCE(IV_INFCOTYPE) TYPE INFCOTYPE_KK
*"
REFERENCE(IV_RECEIVER) TYPE INFCOREC_KK
*" CHANGING
*"
REFERENCE(CT_DATA_SEND) TYPE STANDARD TABLE
*"-----------------------------------------------------------------IT_DFKKINFCO: Table of database entries of Information Container entries
IV_INFCOTYPE: Information container category
IV_RECEIVER: Receiver of the data
CT_DATA_SEND: Table of data to send
This exit is called after the mass activity has filled the data to send. The customer can
enhance the sent data CT_DATA_SEND with his data.
The exit is marked so that additional functions are allowed. Therefore the industries can fill
their send data in the SI includes and the customer can fill their CI include.

2.6.3 Send via RFC (3703)

Interface:
FUNCTION fkk_sample_3703.
*"-----------------------------------------------------------------*"*"Lokale Schnittstelle:
*" IMPORTING

Page 6 of 18

Implementation Guide for FI-CA Information Container

*"
REFERENCE(IT_DATA_SEND) TYPE STANDARD TABLE
*"
REFERENCE(IV_INFCOTYPE) TYPE INFCOTYPE_KK
*"
REFERENCE(IV_RECEIVER) TYPE INFCOREC_KK
*"
REFERENCE(IX_SIMU) TYPE XFELD
*" EXPORTING
*"
REFERENCE(EX_SEND_ERROR) TYPE XFELD
*"
REFERENCE(ET_MESSAGES) TYPE FKK_BAL_MSG_T
*"-----------------------------------------------------------------IT_DATA_SEND: Table of data to send
IV_INFCOTYPE: Information container category
IV_RECEIVER: Receiver of the data
IX_SIMU: Flag if the run is started in simulation mode
EX_SEND_ERROR: Flag, if an error occurred
ET_MESSAGES: Table for messages
This exit is called by the mass activity FPINFCO1, if the data should be sent out via RFC. In
this case we dont know the destination and the customer has to call his RFC in his
destination.

2.6.4 Send via File (3704)

Interface:
FUNCTION fkk_sample_3704.
*"-----------------------------------------------------------------*"*"Lokale Schnittstelle:
*" IMPORTING
*"
REFERENCE(IT_DATA_SEND) TYPE STANDARD TABLE
*"
REFERENCE(IV_INFCOTYPE) TYPE INFCOTYPE_KK
*"
REFERENCE(IV_RECEIVER) TYPE INFCOREC_KK
*" EXPORTING
*"
REFERENCE(ET_STRING) TYPE STRING_TABLE
*"
REFERENCE(EX_ERROR) TYPE XFELD
*"
REFERENCE(ET_MESSAGES) TYPE FKK_BAL_MSG_T
*" CHANGING
*"
REFERENCE(CS_FILENAME) TYPE LOCALFILE OPTIONAL
*"-----------------------------------------------------------------IT_DATA_SEND: Table of data to send
IV_INFCOTYPE: Information Container Category
IV_RECEIVER: Receiver of the data
ET_STRING: Table of strings, which will be saved in the file
EX_SEND_ERROR: Flag, if an error occurred
ET_MESSAGES: Table for messages
CS_FILENAME: Filename
This exit is called by the mass activity FPINFCO1, if the data should be saved in a file. In this
case the customer has to build up the file, which he does by filling ET_STRING.
If the filename is not changed, then the filename will get the following name:
[Information Container Category]_[Run Date]_[Run Identification]_[Work Process ID]
Note: The file can be found with transaction AL11, Directory DIR_HOME.

Page 7 of 18

Implementation Guide for FI-CA Information Container

2.7 Archiving
2.7.1 Archiving Object
FI_MKKINF

2.7.2 Reports
RFKKINFAR01
RFKKINFAR02
RFKKINFAR03

Archiving
Deleting
Reloading

Page 8 of 18

Implementation Guide for FI-CA Information Container

3 Customizing
3.1 Definition of Information Container Categories
The definitions of the Information Container Categories have to be made by SAP.
Nevertheless the customer can also create his own categories (beginning with Z).
Therefore follow the IMG path: Integration -> Information Container -> Define Information
Container Categories (view V_TFKINFCOT).
The following has to be set:
Category: The category has to begin with the application (e.g. V for Insurance). For
FI-CA this does not have to be done.
Description
Implementing class: The implementing class which implements the interface
IF_FKK_INFCO_TYPE.
Storage type: X (XML string) or D (data container)
Structure of the data of process
Structure of the data to store
Structure of the data to send
Storage type:
We recommend using the XML string.
Only if you have a really large data volume (for example, the structure has some tables within
it), then you should use the data container.
Keep in mind that performance is much better when using the XML string

3.2 Customizing of Information Container Categories

The definition of the information container categories have to be made by the customer.
Nevertheless SAP can deliver an initial entry.
Therefore follow the IMG path: Integration -> Information Container -> Make Settings for
Information Container Categories (view V_TFKINFCOTS).
Create an entry for your category. Define a sending type also.
If you want to test your category, you need an entry here. Also the activation flag has to be
set.

Page 9 of 18

Implementation Guide for FI-CA Information Container

4 Definition of structures
4.1 Data of process
This structure includes all data that the process wants to provide to the information container.
The structure should include at least the data which should be stored.
But the data can be more than the data to store, because maybe the customer wants to add
his own data from the process data.
Naming convention (if possible):
[Application]INFCO_[Info Container Category]_ALL
For example, for application FS-CD, category V001: FSCDINFCO_V001_ALL
For example, for application FI-CA, category 0001: FKKINFCO_0001_ALL

4.2 Data to store

This structure includes the data which should be stored for an entry of the information
container category.
The structure should have a CI include for customer data.
In the case of an FI-CA process, the structure should also have SI includes for the industry
enhancements.
Naming convention (if possible):
[Application]INFCO_[Info Container Category]_STORE
For example, for application FS-CD, category V001: FSCDINFCO_V001_STORE
For example, for application FI-CA, category 0001: FKKINFCO_0001_STORE

4.3 Data to send

This structure includes the data which should be sent out.
This structure can be the same as the structure with the data to store, but does not have to
be. Maybe the sending data is less than the data which is stored or more (then data has to be
selected before sending).
The structure should have a CI include for customer data.
In case of an FI-CA process, the structure should also have SI includes for the industry
enhancements.
Naming convention (if possible):
[Application]INFCO_[Info Container Category]_SEND
For example, for application FS-CD, category V001: FSCDINFCO_V001_SEND
For example, for application FI-CA, category 0001: FKKINFCO_0001_SEND

Page 10 of 18

Implementation Guide for FI-CA Information Container

5 Implementation of Interface
Every category has to implement the interface IF_FKK_INFCO_TYPE.
Therefore create your own class which implements the interface.
Naming convention:
CL_[Application]_INFCO_TYPE_[Info Container Category]
For example, for application FS-CD, category V001: CL_FSCD_INFCO_TYPE_V001
For example, for application FI-CA, category 0001: CL_FKK_INFCO_TYPE_0001

5.1 Method IF_FKK_INFCO_TYPE~CHECK_REQUIREMENTS

Interface:

IS_DATA_ALL (importing): Structure with data of process

EX_NOT_FULFILLED (exporting): If no entry should be created for the given data,
this parameter should be set to X.
ERROR (exception): If an error occurs, raise this exception.
This method is optional.
This method can be implemented if there are any prerequisites that have to be fulfilled before
the information container entry should be written.
Maybe you have a special Customizing for writing information container entries.
Example: With FS-CD Information Category V001 entries should be created if the dunning
level changes. But this should only be done for Customized dunning levels. This Customizing
can be checked here.
With this method you dont have to check the Customizing of the information container type.
The check if the category is active is done by the framework.
The method is called before the creation of a new Information Container entry.

5.2 Method IF_FKK_INFCO_TYPE~GET_DATA_STORE

Interface:

IS_DATA_ALL (importing): Structure with data of process

ET_DATA_STORE (exporting): Table with data to store
ET_DATA_MASTER (exporting): Table with master data
ET_DATA_RECEIVER (exporting): Table with receiver data
ERROR (exception): If an error occurs, raise this exception.

Page 11 of 18

Implementation Guide for FI-CA Information Container

This method is mandatory.

With this method you have to fill the data to store.
You get the data of the process into this method and with this data you can create one or
more entries.
For every entry you have to fill the data to store (one line in ET_DATA_STORE) and the
master data (one line in ET_DATA_MASTER).
The lines of ET_DATA_STORE and ET_DATA_MASTER have to be the same. Each line of
ET_DATA_STORE belongs to the corresponding line of ET_DATA_MASTER.
The master data is:
Business Partner (mandatory)
Contract Account (optional)
Contract (optional)
The business partner is mandatory, because it is used as the parallelization object within the
mass activity for sending out the entries.
If the receiver(s) of the information container entry are known, you can directly return a list of
the receivers with parameter ET_DATA_RECEIVER. The ROWINDEX of the structure should
be filled with the corresponding information container entry - that means the corresponding
line of ET_DATA_STORE.
The method is called during the creation of a new information container entry.

5.3 Method IF_FKK_INFCO_TYPE~GET_DATA_SEND

Interface:

IT_DFKKINFCO (importing): Table of database entries of Information Container

entries
IV_RECEIVER (importing): Receiver of the data (reduced to 3 characters)
IV_RECEIVER_LONG (importing): Receiver of the data
ET_DATA_SEND (exporting): Table of data to send
ET_DFKKINFCO_OBSOLETE (exporting): Table of obsolete Information Container
entries
ERROR (exception): If an error occurs, raise this exception
This method is mandatory.
With this method you have to fill the data to send.
You get the database entry of the information container entry into the method. Depending on
the saving type, the data is stored in the field XMLSTRING (saving type XML string) or in the
field DATACONTKEY (saving type data container)
For the conversion of the database data into stored data, you can use the method
CL_FKK_INFCO_SERVICE=>GET_STORE_DATA.

Page 12 of 18

Implementation Guide for FI-CA Information Container

The number of the given database entries (IT_DFKKINFCO) has to be the same as the sum
of the number of data to send (ET_DATA_SEND) and number of obsolete entries
(ET_DFKKINFCO_OBSOLETE).
The method is called during the mass activity for sending out the data (transaction
FPINFCO1).
The number of entries given into the method with IT_DFKKINFCO depends on the type of
sending:
In case of XI or WS-RM:
1 to the XI limit of the mass activity run
In case of RFC:
1 to 50
In case of File:
1 to the database limit of the mass activity run
There are 2 fields for the receiver (IV_RECEIVER and IV RECEIVER_LONG), because with
ERP 6.0, Enhancement Package 4, the receiver field was extended from 3 characters to 60
characters. To be compatible with versions before EhP4, the interface will not be touched. But
the interface got a new field IV_RECEIVER_LONG with 60 characters.
Note: If the receiver is used in the implementation, then always use IV_RECEIVER_LONG
(not IV_RECEIVER)!
The receiver is defined in Customizing (by the customer) and is defined within event 3701.

5.4 Method IF_FKK_INFCO_TYPE~SEND_VIA_XI

Interface:

IT_DATA_SEND (importing): Table of data to send

IV_RECEIVER (importing): Receiver of the data (reduced to 3 characters)
IV_RECEIVER_LONG (importing): Receiver of the data
IX_SIMU (importing): Flag if the run is started in simulation mode
EX_XIGUID (exporting): GUID of the created XI message
EX_SEND_ERROR (exporting): Flag, if an error occurred
ET_MESSAGES (exporting): Table for messages
ERROR (exception): If an error occurs, raise this exception
This method is mandatory, if you have an XI message and you do not send out via WS-RM.
Within this method you call the proxy of your XI message.
If you do not have an XI message, you should export an error message (with
ET_MESSAGES) and set the flag EX_SEND_ERROR.
There are 2 fields for the receiver (IV_RECEIVER and IV RECEIVER_LONG), because with
ERP 6.0, Enhancement Package 4, the receiver field was extended from 3 characters to 60
characters. To be compatible with versions before EhP4, the interface will not be touched. But
the interface got a new field IV_RECEIVER_LONG with 60 characters.
Note: If the receiver is used in the implementation, then always use IV_RECEIVER_LONG
(not IV_RECEIVER)!

Page 13 of 18

Implementation Guide for FI-CA Information Container

5.5 Method IF_FKK_INFCO_TYPE~SEND_VIA_WSRM (from

EhP5 on)
Interface:

IT_DATA_SEND (importing): Table of data to send

IV_RECEIVER (importing): Receiver of the data (reduced to 3 characters)
IV_RECEIVER_LONG (importing): Receiver of the data
IX_SIMU (importing): Flag if the run is started in simulation mode
EX_XIGUID (exporting): GUID of the created XI message
EX_SEND_ERROR (exporting): Flag, if an error occurred
ET_MESSAGES (exporting): Table for messages
ERROR (exception): If an error occurs, raise this exception
This method is mandatory, if you have an XI message and you send out via WS-RM (instead
of XI).
Within this method you call the proxy of your XI message.
In case you dont have an XI message you should export an error message (with
ET_MESSAGES) and set the flag EX_SEND_ERROR.
There are 2 fields for the receiver (IV_RECEIVER and IV RECEIVER_LONG), because with
ERP 6.0, Enhancement Package 4, the receiver field was extended from 3 characters to 60
characters. To be compatible with versions before EhP4, the interface will not be touched. But
the interface got a new field IV_RECEIVER_LONG with 60 characters.
Note: If the receiver is used in the implementation, then always use IV_RECEIVER_LONG
(not IV_RECEIVER)!
In case the sending type is Customized as RFC or File, you do not implement
SEND_VIA_XI or SEND_VIA_WSRM. In this case the framework calls the exit 3703 or
3704.

Page 14 of 18

Implementation Guide for FI-CA Information Container

6 Creation of entries
For the creation of entries the framework offers the class CL_FKK_INFCO_STORE.
This class has 4 methods which are public and you can use.
The recommendation is to create a new function module or method, which calls these 4
methods. The function module/method can then be called from your application to store the
information container entries.
Naming convention for function modules (if possible):
[Application]INFCO_TYPE_[Info Container Category]_STORE
For
example,
for
application
FS-CD,
category
V001:
FSCDINFCO_TYPE_V001_STORE
For example, for application FI-CA, category 0001: FKKINFCO_TYPE_0001_STORE
For your function module you can use the following function groups:
FI-CA: FKKINFCO_TYPE
FS-CD: FSCDINFCO_TYPE
The following 4 methods of class CL_FKK_INFCO_STORE from the framework can be used
for the creation of entries.

6.1 Method Constructor

Interface:

IV_INFCOTYPE (importing): Your Information Container Category

IX_SIMU (importing): Flag for simulation run
INTERNAL_ERROR (exception): If an error occurs, this exception is raised
NOT_ACTIVE (exception): If an error occurs, this exception is raised
First you have to create an instance of the class CL_FKK_INFCO_STORE. Therefore you
have to call CREATE OBJECT.
If you dont want the program to terminate (or bring an error message) when your category is
not active, then EXIT if the exception NOT_ACTIVE is raised.

6.2 Method STORE_SINGLE

Interface:

IS_DATA_ALL (importing): Structure with data of process

EX_ENTRY_STORED (exporting): Flag, that entry is stored
INTERNAL_ERROR (exception): If an error occurs, this exception is raised

Page 15 of 18

Implementation Guide for FI-CA Information Container

EVENT_ERROR (Exception): If an error occurs and a user exists, this exception is

raised
Before calling this method:
An instance of class CL_FKK_INFCO_STORE has to be created (method
Constructor)
You have to build up the structure with the process data
This method creates an information container entry (or more) from the process data. The
entries will be collected and are not yet stored on the database. Therefore you can call this
method several times, if you want to create more entries.

6.3 Method SAVE_ALL

Interface:

IX_UPDATE_TASK (importing): Flag if data should be stored in update task

INTERNAL_ERROR (exception): If an error occurs, this exception is raised
Before calling this method:
An instance of class CL_FKK_INFCO_STORE has to be created (method
Constructor)
Method STORE_SINGLE is called at least one time
This method saves all the information container entries (collected with STORE_SINGLE) to
the database.
Therefore this method can be called in an ON COMMIT routine.

6.4 Method CLEAR_ALL

Before calling this method:
An instance of class CL_FKK_INFCO_STORE has to be created (method
Constructor)
Method STORE_SINGLE is called at least one time
This method clears all the information container entries (collected with STORE_SINGLE) from
the internal memory.
Therefore this method can be called in an ON ROLLBACK routine.

Page 16 of 18

Implementation Guide for FI-CA Information Container

7 Test scenario
After sending out the data we should check if the send has worked, that means, that the data
has reached the external system.
In the case of sending out the data via RFC and XI, the default test scenario is that for the
sent data an entry is created in table DFKKINFCOT in the receiving system.
In the case of sending out the data via file, the default test scenario is that the sending data is
transformed to XML data and this data is saved in a file.
In our test scenarios at SAP the sending system and the receiving system are the same.

7.1 Test scenario XI

7.1.1 Inbound XI message
For the test scenario an inbound XI message should be created in the namespace /Testing.
For more information visit the Wiki page.

7.1.2 Proxy implementation of Inbound XI Message

Within the proxy implementation of the inbound XI message for the test you can do the
following:
1. The first line of your code should be SET UPDATE TASK LOCAL., because this
should be done for all inbound messages which update any data.
2. Map the XI data to your sending data of the information container.
3. Create a new entry in database table DFKKINFCOT.
Therefore you can use the method CL_FKK_INFCO_TEST=>CREATE_TEST_DATA:
CALL METHOD cl_fkk_infco_test=>create_test_data
EXPORTING
it_data_send
= [the mapped data]
iv_sendtype
= cl_fkk_infco_service=>mc_sendtype_xi
ix_simu
= space
ix_update_task = space.

7.2 Test scenario RFC

In the case of sending out the data via RFC, the function module FKK_SAMPLE_3703_TEST
can be called in event 3703.
This function module creates an entry in table DFKKINFCOT.

7.3 Test scenario File

In the case of sending out the data via File, the function module FKK_SAMPLE_3704_TEST
can be called in event 3704.
This function module creates an XML document and writes this to the string table of the
event.
The file can be found in directory DIR_HOME (transaction AL11). The name of the file is the
following:
[Information Container Category]_[Run Date]_[Run Identification]_[Work Process ID]

Page 17 of 18

Implementation Guide for FI-CA Information Container

8 Appendix
8.1 Transactions
FPINFCO1
FPINFCO2
FPINFCO3

Mass activity for sending out entries

Online transaction to view the entries
Reset sending information

8.2 Tables
DFKKINFCO
DFKKINFCOS
DFKKINFCOR
DFKKINFCOT

Information container entries

Sending information
History for the reset of sending data
Table for the test scenario

8.3 Packages
FI-CA Framework: FKKTOOLS
Category 0001: FKKTOOLS
Category 0002: FKKTOOLS
Category V001: VINTEG
Category V002: VINTEG
Category V003: VINTEG
Category V004: VINTEG

Page 18 of 18