Receiving Transaction Processor Conundrum

 

what would we do if we are faced with a situation to execute a receiving transaction in oracle ebusiness suite from a BPEL process in Oracle Fusion Middleware?

There are no public APIs provided as of this moment to execute the transactions. The only option is to use the receiving transaction processor. We would not want to invoke a concurrent program from a BPEL process and write wait & watch logic to check the outcome of the concurrent program. Could there be a better way? Let us dig deeper into how Oracle internally handles the receiving transactions.

Within the ebusiness suite system, there are 3 modes with which receiving can be done: Online, Immediate, Batch.

Immediate mode calls the receiving transaction processor as a concurrent request while the batch mode simply inserts the transactions into the receiving interface which could then be processed by a scheduled run of the receiving transaction processor.

What is of interest to us is this online mode. The online mode invokes the receiving transaction processor as a synchronous call bypassing the concurrent request submission. It is this mode that we can use to our advantage in a BPEL process to pull off our heist.

Synchronous calls can be done using fnd_transaction.synchronous API in the ebusiness suite system. The synchronous call to receiving transaction processor would be like this:

l_retvalue := fnd_transaction.synchronous( 300, -- timeout in seconds
l_outcome, -- out variable indicating Success/Warning/Error
l_message, -- out variable with a descriptive message
‘PO‘,
‘RCVTPO‘,
‘ONLINE‘,
l_group_id, -- group_id in rcv_transactions_interface
l_organization_id, -- inventory organization_id,
NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL);

Please note that Oracle internally makes this call for Online receiving transactions using POR_RCV_ORD_SV.Call_Txn_Processor routine.

There are a couple of things that we need to do before we make this synchronous call:

  • Set the apps context
  • Insert rows into receiving interface tables
  • Specify processing_mode_code in rcv_transactions_interface as ‘ONLINE‘

To debug this routine, set the ‘CONC_DEBUG‘ profile to ‘TC‘ and watch for errors in the fnd_concurrent_debug_info table.

All of this could be wrapped up into a nice custom utility and we would be good to go!

Enjoy the serving!

时间: 2024-10-10 08:00:21

Receiving Transaction Processor Conundrum的相关文章

How Many Processes Should Be Set For The Receiving Transaction Manager (RTM)

In this Document   Goal   Solution   References APPLIES TO: Oracle Inventory Management - Version 10.7 to 12.1.3 [Release 10.7 to 12.1] Information in this document applies to any platform. RCVOLTM - Receiving Transaction Manager GOAL What Is Correct

How to SetUp The Receiving Transaction Manager

In this Document Goal Solution References APPLIES TO: Oracle Inventory Management - Version: 10.7 to 12.1.3 - Release: 10.7 to 12.1 Information in this document applies to any platform. ***Checked for relevance on 21-Mar-2012*** EXECUTABLE:RCVTPO - R

Oracle Order Management DropShip Flow for R12

Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest In this blog I will explain Oracle  Drop Ship Flow for R12i.What is Dropship Order - In dropship Order, sales order line creates a requisition line that becomes a PO and sent to y

projecteuler---->problem=20----Factorial digit sum

1. 拿到一个新 bug, 首先要重现问题. 这对 code 问题是必须的, 对客户的 data 问题, 几乎也是必须的. 如果是 code 问题, 不重现就没办法修改代码, 改好了也无法验证是不是改对了. 客户的 data 出问题, 多数情况也是能够重现的. 毕竟客户是用我们的系统操作的, 只要拿到客户的历史数据, 对照着是可以自己做出同样的数据. 以前我遇到 data fix 的时候不喜欢重现, 都是凭感觉给出脚本. 但这样常常忽略一些重要的数据, 容易出错. 如果确定是 data fix,

RTP 记录 log 的机制

我们 RCV 这边经常跑的一个concurrent request RTP: Receiving Transaction Processor, 主要是用来处理 RCV_TRANSACTIONS_INTERFACE 里面的数据的. 这个 concurrent program 里面包含许多文件, 比较重要的有: ident RVCTP RVCTP: $Header: rvctp.oc 120.0.12000000.1 2007/01/16 23:53:49 appldev ship $ $Heade

所有标准API

序号 系统版本 模块 应用场景 类型 API/接口 参数规格 样例代码 备注 登记者 登记时间 关键字 1 12.1.3 AP 付款核销 API ap_pay_invoice_pkg.ap_pay_invoice 赵杨 2013/3/30 付款/核销 2 12.1.3 AP 应付发票审批 API ap_approval_pkg.approval 赵杨 2013/3/30 发票/审批 3 12.1.3 AP 预付款核销 API ap_prepay_pkg.apply_prepay_fr_prepa

LeetCode: Path Sum [112]

1. 拿到一个新 bug, 首先要重现问题. 这对 code 问题是必须的, 对客户的 data 问题, 几乎也是必须的. 如果是 code 问题, 不重现就没办法修改代码, 改好了也无法验证是不是改对了. 客户的 data 出问题, 多数情况也是能够重现的. 毕竟客户是用我们的系统操作的, 只要拿到客户的历史数据, 对照着是可以自己做出同样的数据. 以前我遇到 data fix 的时候不喜欢重现, 都是凭感觉给出脚本. 但这样常常忽略一些重要的数据, 容易出错. 如果确定是 data fix,

拿到一个新 bug 怎样分析

1. 拿到一个新 bug, 首先要重现问题. 这对 code 问题是必须的, 对客户的 data 问题, 几乎也是必须的. 如果是 code 问题, 不重现就没办法修改代码, 改好了也无法验证是不是改对了. 客户的 data 出问题, 多数情况也是能够重现的. 毕竟客户是用我们的系统操作的, 只要拿到客户的历史数据, 对照着是可以自己做出同样的数据. 以前我遇到 data fix 的时候不喜欢重现, 都是凭感觉给出脚本. 但这样常常忽略一些重要的数据, 容易出错. 如果确定是 data fix,

Parallelized coherent read and writeback transaction processing system for use in a packet switched cache coherent multiprocessor system

A multiprocessor computer system is provided having a multiplicity of sub-systems and a main memory coupled to a system controller. An interconnect module, interconnects the main memory and sub-systems in accordance with interconnect control signals