Oracle Communications Billing and Revenue Management (Oracle BRM \ formally known as Portal Infranet) 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. For a number of reasons, I prefer the latter choice, and in this post I 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 Oracle DM or Microsoft SQL Server DM configuration file (BRM_HOME/sys/dm_oracle/pin.conf or BRM_HOME/sys/dm_odbc/pin.conf) in a text 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
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:
1. PCM_OP_SDK_SET_FLD_SPECS – create or modify a field,
2. PCM_OP_SDK_GET_FLD_SPECS – retrieve a field specs,
3. 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”
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.
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 C_FLD_VAT_NUMBER PIN_MAKE_FLD(PIN_FLDT_STR, 10000)
The line above defines a custom field named “C_FLD_VAT_NUMBER” (mind the naming practice,
PIN_* for BRM fields and C_* for custom fields) 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
