Custom fields in Oracle BRM

Oracle Communications Billing and Revenue Management offers two methods for creating, editing and deleting custom fields and storable classes. One approach is by using Storable Class Editor, part of the Developer Center application, and the other is by using SDK opcodes.

This post will address manipulating custom fields with SDK opcodes.

Before beginning, one change needs to be made first: making the data dictionary writable. Here’s how to do it:

1. Open the DM Oracle configuration file ($BRM_HOME/sys/dm_oracle/pin.conf) in a text(e.g. vi) editor.

2. Enable field manipulation in the data dictionary, by setting the following entry to 
1:-  dm dd_write_enable_fields 1

Our objectives are as follows:

1. To create a custom field

2. To edit the custom field description

3. To delete the custom field from the database

4. To make the custom field available to BRM

1. Creating a New Custom Field

Creating a new custom field and committing it to the database can be accomplished with SDK opcodes or with a pin deploy utility. As developers know, SDK opcodes provide a more flexible way to create, edit, and delete custom fields at the development stage. The pin deploy utility, on the other hand, uses PODL (Portal Object Definition Language) to export and import  field and storable class definitions. This is more useful, especially at the administrative level, because the process can be streamlined by putting field definitions into source code management and thus lower any possibility of damaging the Oracle BRM production database data dictionary.

The following SDK opcodes can be used to manage field specifications:

i. PCM_OP_SDK_SET_FLD_SPECS – create or modify a field,

ii. PCM_OP_SDK_GET_FLD_SPECS – retrieve a field specs,

iii. PCM_OP_SDK_DEL_FLD_SPECS – delete a field.

To create a field, it’s necessary to write an input flist for PCM_OP_SDK_SET_FLD_SPECS opcode:

0 PIN_FLD_POID POID [0] 0.0.0.1 /dd/fields 0 0

0 PIN_FLD_FIELD ARRAY [0]

1    PIN_FLD_DESCR STR [0] “custom field for holding a VAT number”

1    PIN_FLD_FIELD_NAME STR [0] “C_FLD_VAT_NUMBER”

1    PIN_FLD_FIELD_NUM ENUM [0] 10000

1    PIN_FLD_FIELD_TYPE INT [0] 5

Now, verify that the field created exists in the database data dictionary by feeding the following input flist to PCM_OP_SDK_GET_FLD_SPECS opcode:

0 PIN_FLD_POID      POID [0] 0.0.0.1 /dd/objects 0 0

0 PIN_FLD_FIELD    ARRAY [0]

1    PIN_FLD_FIELD_NAME    STR [0] “C_FLD_VAT_NUMBER”

2. Editing the Custom Field Description

Now, having confirmed that the new custom field exists, the description can be altered by calling PCM_OP_SDK_SET_FLD_SPECS opcode with the following input flist:

0 PIN_FLD_POID POID [0] 0.0.0.1 /dd/fields 0 0

0 PIN_FLD_FIELD ARRAY [0]

1    PIN_FLD_DESCR STR [0] “custom field – VAT number”

1    PIN_FLD_FIELD_NAME STR [0] “C_FLD_VAT_NUMBER”

1    PIN_FLD_FIELD_NUM ENUM [0] 10000

1    PIN_FLD_FIELD_TYPE  INT [0] 5

Again, the field’s specifications can be retrieved so as to verify that the change has been accomplished.

After that, delete the custom field from the database.

Finally, assume a mistake has been made, and it’s necessary to delete a field. Provide the following input flist to PCM_OP_SDK_DEL_FLD_SPECS opcode, deletes the field:

0 PIN_FLD_POID POID [0] 0.0.0.1 /dd/fields 0 0

0 PIN_FLD_FIELD ARRAY [0]

1    PIN_FLD_FIELD_NAME STR [0] “C_FLD_VAT_NUMBER”

If the opcode for retrieving the field’s specifications returns an empty flist (only POID obj),then that signifies the field was not found in the database data dictionary.

3. Making the Custom Fields Available to BRM

Standard practice dictates that everything custom developed goes into the BRM_HOME/custom directory, and since, in this case, BRM_HOME/include/pin_flds.h, is being extended, a new custom header file BRM_HOME/custom/include/custom_flds.h. needs to be created.

Now, the new custom field can be introduced by appending the following line to custom_flds.h:

#define MY_CUSTOM_FLD PIN_MAKE_FLD(PIN_FLDT_STR, 10000)

The line above defines a custom field named “MY_CUSTOM_FLD” with data type “PIN_FLDT_STR” (STR stands for string) and unique identifier “10000″ (in regards to BRM_HOME/include/pin_flds.h).

Data types are static, and defined by the BRM version you are running; please see BRM_HOME/include/pcm.h for definitions.

Next, run the parse_custom_ops_fields.pl perl script on the custom_flds.h using this command:

$BRM_HOME/bin/parse_custom_ops_fields.pl -L pcmc -I custom_flds.h -O $BRM_HOME/custom/include/custom_mapping.m

And finally, include the following line to every pin.conf where it’s desired that these field be seen: –

- ops_fields_extension_file ${BRM_HOME}/custom/include/custom_mapping.m

NOTE: When introducing new functionalities using custom fields, it is necessary to include the custom_flds.h header file in the FMs that use these fields