事务处理接口分析

我们现在对事务处理接口的理解，我想，很多人跟我的理解一样，还停留在只知道有两个接口表，或者说，知道一接口一临时表的程度。到底这两个表功能有什么区别？各自是如何运作的？

    本文我将带着这些疑问，和大家一起进入讨论。

 



看看Oracle给他们的解释：<右边框给出比较>

MTL_TRANSACTIONS_INTERFACE

MTL_TRANSACTIONS_INTERFACE is the interface point between

non– Inventory applications and the Inventory transaction module.

Transaction Manager concurrent program polls this table at a

user–specified process interval, and submits the Transaction Workers to

process them. Processing consists of data derivation, validation, and

transfer of records from MTL_TRANSACTIONS_INTERFACE,

MTL_TRANSACTION_LOTS_INTERFACE, and

MTL_SERIAL_NUMBERS_INTERFACE into their respective TEMP

tables, from where they are processed by the transaction processor.

MTL_TRANSACTIONS_INTERFACE follows the Inventory standard

for interfacing flexfields. Any parameters which are represented by

flexfields may be entered in the interface table either as code

combination identifiers or as flexfield segment combinations. The

Transaction Worker will validate that any given identifiers are valid

and enabled. If no identifier is given, then the Transaction Worker will

validate and decode the flexfield segment values, and where

appropriate, create new flexfield combinations in the database.

The Transaction Manager picks up the rows to process based on the

LOCK_FLAG, TRANSACTION_MODE, PROCESS_FLAG to

manipulate the records in the table. Only records with

TRANSACTION_MODE of 3, LOCK_FLAG of ’2’, and

PROCESS_FLAG of ’1’ will be picked up by the Transaction Manager

and assigned to a Transaction Worker. If a record fails to process

completely, then PROCESS_FLAG will be set to ’3’ and ERROR_CODE
1、Interface是连接非库存系统与库存系统的桥梁

2、Interface的数据经常事务管理并发处理后，将插入对应的临时表，再由事务处理器处理。

3、数据处量条件限制请见左边

MTL_MATERIAL_TRANSACTIONS_TEMP

MTL_MATERIAL_TRANSACTIONS_TEMP is the gateway for all

material transactions.

Records are processed from this table into Inventory through the

transaction processor. All Inventory transaction forms write directly to

this table. Outside applications must write transaction records to

MTL_TRANSACTIONS_INTERFACE to be processed through

MTL_MATERIAL_TRANSACTIONS_TEMP and the transaction

processor by the Transaction Worker concurrent program.

Lots and serial numbers for a

MTL_MATERIAL_TRANSACTIONS_TEMP(MMTT) record are stored

in the tables MTL_TRANSACTION_LOTS_TEMP(MTLT) and

MTL_SERIAL_NUMBERS_TEMP(MSNT). If the item is under lot

control, then MMTT.TRANSACTION_TEMP_ID joins to

MTLT.TRANSACTION_TEMP_ID. If the item is also under serial

number control, then MTLT.SERIAL_TRANSACTION_TEMP_ID joins

to MSNT.TRANSACTION_TEMP_ID. If the item is only under serial

number control, then MMTT.TRANSACTION_TEMP_ID joins to

MSNT.TRANSACTION_TEMP_ID.

Transfer transactions are stored in this table as a single record. The

transaction processor creates two transactions from the single record.
看看左边的红色标识的话：所有事务处理的必经的步骤。



所有插入事务处理正式表的数据，都必须经过TEMP表后，（自动）运行Transaction Processor后插入正式表。





从Oracle官方给出的解释，我们可以基本上得到如下一个逻辑图：

如果照上图描述，那么，我们能否通过一些实例来来说明或者说证明我们的想法呢？

   

    一、先了解它



首先，我们明确一下这两个表：

   临时表： MTL_MATERIAL_TRANSACTIONS_TEMP （以下简称TEMP表）

   接口表： MTL_TRANSACTIONS_INTERFACE       （以下简称INTERFACE表）

  



二、运用它

OK，我们已经知道这两个TABLE的区别及流程，那么，我们怎么运用它呢？



接下来我们针对这两个表分别具体来描述它们的运用。



1）   Interface

·直接插入数据入接口表。这里面有几个需要注意的地方：

  



字段
描述

Source_code, Source_header_id, Source_line_id
来源行，供追溯使用，可以随便填

transaction_source_name
事务处理来源名称，可以随便指定。

PROCESS_FLAG
transaction is ready to be processed by the Transaction

Manager or Worker (’1’ for ready, ’2’ for not ready); if

the transaction fails for some reason, the Transaction Worker sets the value of PROCESS_FLAG to ’3’

TRANSACTION_MODE
the transaction is to be processed in immediate

concurrent processing mode (2) or background processing mode(3)

LOCK_FLAG
Flag indicating whether the transaction is locked by the

Transaction Manager or Workers (’1’ for locked, ’2’ or NULL

for not locked); this prevents two different Workers from

processing the same transaction; You should always specify ’2’

TRANSACTION_TYPE_ID
Transaction type identifier，这里要注意一下的是，如果你是做做杂项处理，那么，如果事务处理数据小于0，那么应该指定为32（Miscellaneous issue），反之则为42（Miscellaneous receipt）

Organization_id

Inventory_item_id

subinventory_code

locator_id

revision

transfer_organization

transfer_subinventory
指定传送仓库及物品有关的信息，如果这些值有，请指定。

transaction_quantity

transaction_uom

transaction_cost

transaction_date
指定事务处理的数量、单位、成本等信息，成本的话，如果指定为NULL，系统会以事务处理器运行时的成本出（入）库。请慎重指定。

distribution_account_id
如果是杂项出入库，请指定库存成本帐户，如果是帐户别名出入库，则需指定。

WHO 字段
需要指定



  

插入数据完成后，那么，按我们的流程，需要进行Transaction Processor，进行后续数据处理

简称：INCTCM

参数：无

提交语句Sample：

    l_request_id    := fnd_request.submit_request('INV',

                                               'INCTCM',

                                               '',

                                               to_char(sysdate,'YYYY/MM/DD HH24:MI:SS'),

                                               false,

                                               chr(0))



1）   TEMP

在INV的内部处理中，系统都会直接将Process插入至TEMP表，再通过自动请求Transaction Processor，将数据导入至正式表中。

直接插数据入TEMP表一般存在于INV模块，不过，ORACLE官方并不太支持这种方式，“Load the transaction records into MTL_TRANSACTIONS_INTERFACE table .Loading the transaction records directly into MTL_MATERIAL_TRANSACTIONS_TEMP table is not supported.”

那么，能不能这么做呢？

其实，Oracle这句话是正确的，人家是说“你可以直接插MTI，但你不能直接插数据入MMTT”。

因为这两者有区别的：MMTT表是联机处理用的，也就是说是form通过API往里面写数据并可以用API直接处理的，MTI表是接口表，里面的数据是通过Conc Req转到MMTT中并通过txn worker来处理的。



OK，理解这一条后，我们很容易就想到这个问题，MMTT的API是什么？API的工作机制是什么样的？

首先来说MMTT的API，我们随机打开了一个RORM－杂项事务处理FORM，它的主BLOCK就是基于MMTT的，在Trigger Pre-Insert中，写了很多前期处理的操作：如取Temp transaction id，如果系统启用了批次/序列，需要在LOT的BLOCK中先写入相关的信息。插表的操作即通过标准API APP_STANDARD.KEY_COMMIT来完成，将数据保存至MMTT中。

所以，我觉得（没实验过）我们完全可以模仿ORACLE标准FORM来往MMTT中插入数据，但是，这前期涉及的针对批次、序列的处理可能会相当烦锁，如果没有这些麻烦，往MMTT中插数据可能与MTI中插数据一样简单。

在这里我先将TEMP表几个关键字段列出来：

字段
描述

TRANSACTION_HEADER_ID

TRANSACTION_TEMP_ID
Header_id为主键，即MMTT的KEY，TEMP ID可有可无，即未来的Transaction ID

TRANSACTION_SOURCE_TYPE_ID
固定值，一般有如下值

1 Purchase order

2 Sales order

3 Account number

4 Job or schedule

5 Job or schedule

6 Account alias

SOURCE_CODE

SOURCE_LINE_ID
来源码和来源行ID

TRANSACTION_MODE
the transaction is to be processed in immediate

concurrent processing mode (2) or background processing mode(3)

LOCK_FLAG
Flag indicating whether the transaction is locked by the

Transaction Manager or Workers (’1’ for locked, ’2’ or NULL

for not locked); this prevents two different Workers from

processing the same transaction; You should always specify ’2’

TRANSACTION_TYPE_ID
Transaction type identifier，这里要注意一下的是，如果你是做做杂项处理，那么，如果事务处理数据小于0，那么应该指定为32（Miscellaneous issue），反之则为42（Miscellaneous receipt）

Organization_id

Inventory_item_id

subinventory_code

locator_id

revision

transfer_organization

transfer_subinventory
指定传送仓库及物品有关的信息，如果这些值有，请指定。

transaction_quantity

transaction_uom

transaction_cost

transaction_date
指定事务处理的数量、单位、成本等信息，成本的话，如果指定为NULL，系统会以事务处理器运行时的成本出（入）库。请慎重指定。

distribution_account_id
如果是杂项出入库，请指定库存成本帐户，如果是帐户别名出入库，则需指定。

WHO 字段
需要指定





三、实践它

我们已经大概知道两者的描述、区别、运用了。那么，我们接下来做几个SAMPLE实验一下

先验证Interface，再验证Temp