| Oracle® Application Server Integration B2B User's Guide 10g Release 2 (10.1.2) Part Number B19370-03 |
|
|
View PDF |
| Oracle® Application Server Integration B2B User's Guide 10g Release 2 (10.1.2) Part Number B19370-03 |
|
|
View PDF |
Inbound messages to OracleAS Integration B2B are automatically debatched. Individual transactions are sent to the internal delivery channel one transaction at a time. For outbound messages received on the internal delivery channel, transaction sets can be batched based on criteria that you specify.
This chapter contains the following topics:
To enable outbound batching, you must update the B2B_BATCH_EVENT table, shown in Table 14-1.
Table 14-1 B2B_BATCH_EVENT Table
| Name | Null? | Type | Description |
|---|---|---|---|
|
ID |
not null |
VARCHAR2(256) |
Randomly generated uuid |
|
EXPIRE_TIME |
- |
DATE |
Date and time when batching occurs |
|
INTERVAL |
- |
NUMBER(38) |
Time interval for the next batching to occur (in minutes) |
|
TOTPNAME |
- |
VARCHAR2(256) |
Trading partner to whom the batch file is sent |
|
DOCTYPE |
- |
VARCHAR2(256) |
Document type, such as ORDERS for EDIFACT or 850 for EDI X12 |
|
DOCTYPEREV |
- |
VARCHAR2(256) |
Document type revision, such as D98A or 4010 |
|
MSGCOUNT |
- |
NUMBER(38) |
Not used; defaults to 1 |
|
STATE |
- |
NUMBER(38) |
Not used; defaults to 1 |
|
ENABLE |
- |
NUMBER(38) |
1 indicates that batching is enabled. 0 indicates that batching is disabled. |
|
CRITERIA1 |
- |
VARCHAR2(256) |
Used for full batching support. The following options are supported:
|
|
CRITERIA2 |
- |
VARCHAR2(256) |
Not used |
|
CRITERIA3 |
- |
VARCHAR2(256) |
Not used |
|
CRITERIA4 |
- |
NUMBER(38) |
Not used |
|
CRITERIA5 |
- |
NUMBER(38) |
Not used |
The following examples show how to batch the document type ORDERS, revision D98A, to the trading partner named GlobalChips. The examples follow the scenario described in the EDI EDIFACT tutorial. TOTPName, DocType, and DocTypeRev in the following example are used in the tutorial. See"Tutorial 2: Setting Up an EDI EDIFACT over Generic (VAN) Transaction" for more information.
To batch DOCTYPE ORDERS revision D98A to GlobalChips (the trading partner) at 3 pm every day:
SQL> insert into B2B_BATCH_EVENT values ((select sys_guid() from dual),
to_date('Fri 03-Dec-2004 15:00:00', 'Dy DD-Mon-YYYY HH24:MI:SS'),
1440, 'GlobalChips', 'ORDERS', 'D98', 1,1,1, null,null,null,null,null);
To batch DOCTYPE ORDERS revision D98A to GlobalChips (the trading partner) every hour starting on Friday, December 3, 2004 at 15:00:00:
SQL> insert into B2B_BATCH_EVENT values ((select sys_guid() from dual),
to_date('Fri 03-Dec-2004 15:00:00', 'Dy DD-Mon-YYYY HH24:MI:SS'),
60, 'GlobalChips', 'ORDERS', 'D98', 1,1,1, null,null,null,null,null);
The unique constraint applies to TOTPNAME, DOCTYPE, and DOCTYPEREV for each row.
Purging the entire repository in the OracleAS Integration B2B user interface does not purge data in the newly created tables for outbound batching. To purge these tables, rerun patch.sql.
The objects in these tables are not currently exported when users export a configuration. Export the B2B_PENDING_MSGS and B2B_PATCH_EVENT tables using the exp tool in Oracle_Home/bin.
For full outbound batching support, you must still enter one row into the B2B_BATCH_EVENT table for each document type and revision you want to send to the trading partner. For backward compatibility, if you leave the column CRITERIA1 as null, the B2B Server batches one document type at one time. If you set CRITERIA1=X12_ONE_TP or EFT_ONE_TP, then the B2B Server batches all X12 or EDIFACT documents that have been entered into the B2B_BATCH_EVENT table for each trading partner.
For example, assume that the B2B_BATCH_EVENT table has the following data:
TOTPNAME, DOCTYPE, DOCTYPEREV, CRITERIA1 GlobalChips, 850, 4010, X12_ONE_TP GlobalChips, 810, 4030, X12_ONE_TP GlobalChips, 855, 4010, X12_ONE_TP Oracle, 810, 3050, X12_ONE_TP Oracle, 850, 3050, X12_ONE_TP Oracle, 855, 3050, X12_ONE_TP
The B2B Server batches 810, 850, and 855 for GlobalChips and 810, 850 and 855 for Oracle (that is, batched into two wire messages).
If you set CRITERIA1=X12_ALL_TP or EFT_ALL_TP, the B2B Server batches all X12 or EDIFACT documents entered into the B2B_BATCH_EVENT table for all the trading partners.
For example, assume that the B2B_BATCH_EVENT table has the following data:
TOTPNAME, DOCTYPE, DOCTYPEREV, CRITERIA1 GlobalChips, 850, 4010, X12_ALL_TP GlobalChips, 810, 4030, X12_ALL_TP GlobalChips, 855, 4010, X12_ALL_TP Oracle, 810, 3050, X12_ALL_TP Oracle, 850, 3050, X12_ALL_TP Oracle, 855, 3050, X12_ALL_TP
The B2B Server batches 810, 850, and 855 for GlobalChips and Oracle into one wire message.
You cannot mix and match for %_ALL_TP and %_ONE_TP. If you use X12_ALL_TP, then all CRITERIA1 values must be X12_ALL_TP. Similarly, if you use X12_ONE_TP, all CRITERIA1 values must be X12_ONE_TP.
For example, the following data is not allowed:
TOTPNAME, DOCTYPE, DOCTYPEREV, CRITERIA1 GlobalChips, 850, 4010, X12_ALL_TP GlobalChips, 810, 4030, X12_ALL_TP GlobalChips, 855, 4010, X12_ALL_TP Oracle, 810, 3050, X12_ONE_TP Oracle, 850, 3050, X12_ONE_TP Oracle, 855, 3050, X12_ONE_TP
However, since you batch X12 and EDIFACT separately, you can have the following data:
GlobalChips, 850, 4010, X12_ONE_TP GlobalChips, 810, 4030, X12_ONE_TP GlobalChips, 855, 4010, X12_ONE_TP Oracle, 810, 3050, X12_ONE_TP Oracle, 850, 3050, X12_ONE_TP Oracle, 855, 3050, X12_ONE_TP Sun, ORDERS, D98A, EFT_ALL_TP Sun, ORDRSP, D98A, EFT_ALL_TP Sun, INVOIC, D98A, EFT_ALL_TP Intel, ORDERS, D98A, EFT_ALL_TP Intel, ORDRSP, D98A, EFT_ALL_TP Intel, INVOIC, D98A, EFT_ALL_TP
The EXPIRE_TIME and INTERVAL must be the same for each batch group. In the preceding example, this syntax,
GlobalChips, 850, 4010, X12_ONE_TP GlobalChips, 810, 4030, X12_ONE_TP GlobalChips, 855, 4010, X12_ONE_TP
is treated as one batch group and these rows must have the same EXPIRE_TIME and INTERVAL. In this example,
Oracle, 810, 3050, X12_ONE_TP Oracle, 850, 3050, X12_ONE_TP Oracle, 855, 3050, X12_ONE_TP
is treated as one batch group and these rows must have the same EXPIRE_TIME and INTERVAL. The EXPIRE_TIME and INTERVAL can be different from the first group, but within the rows of the second group, the value for EXPIRE_TIME and INTERVAL must be the same. In this example,
Sun, ORDERS, D98A, EFT_ALL_TP Sun, ORDRSP, D98A, EFT_ALL_TP Sun, INVOIC, D98A, EFT_ALL_TP Intel, ORDERS, D98A, EFT_ALL_TP Intel, ORDRSP, D98A, EFT_ALL_TP Intel, INVOIC, D98A, EFT_ALL_TP
is treated as one batch group and these rows must have the same EXPIRE_TIME and INTERVAL.
In most cases, you must also set this property in the tip.properties file: oracle.tip.adapter.b2b.edi.identifyFromTP=Interchange. This is because batch messages have many Interchange Sender and Receiver IDs.
As a result, you also must create a trading partner identification type called EDI Interchange ID and create a value for this type in the host or remote trading partner corresponding to the Interchange Sender and Receiver IDs in the EDI message.
