BRM Transaction Policy Opcodes Communicating With Each Other
(Doc ID 2619392.1)
Last updated on DECEMBER 11, 2019
Applies to:Oracle Communications Billing and Revenue Management - Version 126.96.36.199.0 and later
Information in this document applies to any platform.
On : 188.8.131.52.0 version, DM
BRM Transaction Policy Opcodes communicating with each other
The document (https://docs.oracle.com/cd/E16754_01/doc.75/e16702/prg_writing_client.htm#BRMDR724) says:
To customize how to open transactions, use PCM_OP_TRANS_POL_OPEN.
This opcode gets the same flist that PCM_OP_TRANS_OPEN does. The return flist then becomes the transaction ID flist; it can contain whatever you want to put in it. That flist then becomes the input to PCM_OP_TRANS_POL_COMMIT and PCM_OP_TRANS_POL_ABORT. The return flists from those opcodes are ignored.
However, the customer is unable to get anything available to PCM_OP_TRANS_POL_COMMIT (or ABORT). The customer sees the transaction flist from PCM_OP_TRANS_POL_OPEN in PCM_OP_TRANS_POL_PREP_COMMIT, but nothing in the (post commit) PCM_OP_TRAN_POL_COMMIT. So it is not able to communicate any information to the post-commit (or post-abort) opcodes from anywhere within the transaction.
Note that a global flist pointer does not seem to be generally recommended as we can have parallel transactions within the same CM child using additional CM contexts.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document