My Oracle Support Banner

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 7.5.0.21.0 and later
Information in this document applies to any platform.

Symptoms

On :  7.5.0.21.0 version, DM

ACTUAL BEHAVIOR  
---------------
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.


Actual result:
========



Changes

 

Cause

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
Symptoms
Changes
Cause
Solution
References


My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.