Ensure the data dictionary is writable before adding or changing fields and storable classes.

Perform the following for each database in your system:

1. Enable changes to the data dictionary by doing the following:

   1. Open the dm-oracle-pin-conf-config ConfigMap.

   2. Ensure the following fields are set to 1:

      data:
        pin.conf: |
          - dm dd_write_enable_fields 1
          - dm dd_write_enable_objects 1

   3. Save and close the file.

2. (Optional) To increase the size of the CM cache for the data dictionary, do the following:

   1. Open the cm-pin-conf-config ConfigMap.

   2. Increase the cacheSize value in the following entries:

      data:
        pin.conf: |
          - cm_cache cm_data_dictionary_cache numberOfEntries, cacheSize, hashSize
          - cm_cache fm_utils_data_dictionary_cache numberOfEntries, cacheSize, hashSize

   3. Save and close the file.

3. (Optional) To configure whether the DM runs Data Definition Language (DDL) when updating object types in the data dictionary tables, do the following:

   1. Open the dm-oracle-pin-conf-config ConfigMap.

   2. Set the following entry:

      data:
        pin.conf: |
          - dm sm_oracle_ddl value

      where value is 1 to run DDLs when updating object types or 0 not to run them. Setting value to 1 ensures that database objects are mapped to the correct tables.

   3. Save and close the file.

4. Run the helm upgrade command to update the BRM Helm release:

   helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

   where:

   • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

   • OverrideValuesFile is the file name and path to your override-values.yaml file.

   • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

You can run the BRM SDK opcodes in the BRM cloud native system without entering a pod by running the testnap utility through a configurator job. For more information about:

• The testnap utility's syntax and parameters, see "testnap" in BRM Developer's Guide.

• Configurator jobs, see "Running Load Utilities through Configurator Jobs".

To run the BRM SDK opcodes:

1. Create a testnap script with the following content:

   r << XXX 1
   flistContent
   XXX
   xop opcodeNumber bufferNumber

   where:

   • flistContent is the input flist for the BRM SDK opcode you want to run.

   • opcodeNumber is the number of the BRM SDK opcode to run. For the list of opcode numbers for the BRM SDK opcodes, see Table 10-1 and Table 10-2.

   • bufferNumber is the internal buffer number used to load the opcode's input flist file.

2. Add the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script:

   #!/bin/sh 
   
   cd /oms/sys/data/config; testnap testnapScript
   exit 0;

   where testnapScript is the name and path to the testnap script you created.

3. Move testnapScript to the oc-cn-helm-chart/config_scripts directory.

4. In the override-values.yaml file for oc-cn-helm-chart, set ocbrm.config_jobs.run_apps to true.

5. Run the helm upgrade command for oc-cn-helm-chart:

   helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile --namespace BrmNameSpace

Table 10-1 describes the BRM SDK opcodes to run for creating, modifying, deleting, and retrieving storable classes.

Table 10-2 describes the BRM SDK opcodes to run for creating, modifying, deleting, and retrieving field definitions.

After you create custom fields and storable classes, you must make them available to your BRM cloud native applications. The first step is to create a C header file, and then you generate a Java package with the custom storable classes.

To make custom fields available to your BRM cloud native applications written in PCM C or PCM C++:

1. Create a C header file for your custom fields. For information about the syntax to use in a header file, view the BRM_home/include/pin_flds.h file in the brm-sdk pod.

2. Enable the brm-sdk pod if you haven't already done so.

   1. Set these keys in your override-values.yaml file for oc-cn-helm-chart:

      brm_sdk:
         isEnabled: true
         deployment:  
            imageName: brm_sdk
            imageTag: 15.0.x.0.0
         pvc:             
            storage: 50Mi 

   2. Run the helm upgrade command for oc-cn-helm-chart:

      helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

      where:

      • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

      • OverrideValuesFile is the path to a YAML file that overrides the default configurations in the values.yaml file for oc-cn-helm-chart.

      • BrmNameSpace is the namespace in which BRM Kubernetes objects were created for oc-cn-helm-chart.

3. Copy your C header file to the brm-sdk pod:

   cp fileName oc-cn-helm-chart/brm_sdk_scripts/
   helm upgrade BrmReleaseName oc-cn-helm-chart --namespace BrmNameSpace --values OverrideValuesFile

   where fileName is the name of your C header file.

   For example, if the C header file is named cust_flds.h:

   cp cust_flds.h oc-cn-helm-chart/brm_sdk_scripts/ 
   helm upgrade BrmReleaseName oc-cn-helm-chart --namespace BrmNameSpace --values OverrideValuesFile

   Afterward, the files from oc-cn-helm-chart/brm_sdk_scripts/ are available at /oms/load in the brm-sdk pod.

4. Find the name of the brm-sdk pod:

   kubectl get pods --namespace BrmNameSpace | grep brm-sdk

   You should see something similar to this:

   NAME                       READY    STATUS     RESTARTS    AGE
   brm-sdk-f67b95777-bf8j5    1/1      Running    0           18m

   In this case, the brm-sdk pod name (brmSDKPodName) is brm-sdk-f67b95777-bf8j5.

5. Run the kubectl exec command to get a shell to the running brm-sdk container:

   kubectl exec -it --namespace BrmNameSpace brmSDKPodName bash

   For example:

   kubectl exec -it --namespace BrmNameSpace brm-sdk-f67b95777-bf8j5 bash

6. In your shell, go to the /oms/load directory and run the parse_custom_ops_fields.pl script with the custom source file:

   perl parse_custom_ops_fields -L pcmc -I filename -O custFlds -P javaPackageName

   where:

   • custFlds: Specifies the name and the location of the memory-mapped output file to create.

   • javaPackageName: Specifies the name of the Java package in which to create the generated classes.

   For example, if the C header file is named cust_flds.h:

   perl parse_custom_ops_fields -L pcmc -I cust_flds.h -O outputFile -P javaPackageName

   For information about the parameters and syntax for parse_custom_ops_fields, see "parse_custom_ops_fields" in BRM Developer's Guide.

7. Configure one or more BRM applications to access your custom fields by doing the following for each BRM application:

   1. Open the application's oc-cn-helm-chart/templates/configmap_pin_conf_*.yaml file.

   2. Add the following entry, replacing custFlds with the file name and location of the memory-mapped output file that parse_custom_ops_fields created:

      - - ops_fields_extension_file custFlds

      Note:

      Do not add more than one ops_fields_extension_file entry. The custom fields source file and the extension file that results from it contain information about all the custom fields in the data dictionary, so a single reference to that file is sufficient.

   3. Include the cust_flds.h header file in the applications and FMs that use the custom fields.

      Note:

      Default BRM fields are defined with their numbers in the BRM_home/include/pin_flds.h file in the brm-sdk pod. While it is possible to add custom fields directly to pin_flds.h, you should not do so. Placing custom field definitions in the separate cust_flds.h file allows you to upgrade to new releases without having to edit pin_flds.h.

Configure one or more BRM applications to access your custom fields by doing the following:

1. Create a Java source file for each custom field.

2. Do the following for each application:

   1. Open the application's oc-cn-helm-chart/templates/configmap_infranet_properties_*.yaml file.

   2. Add properties for configuring your custom field and source file.

   3. Save and close the file.

3. Compile the Java source files you created in Step 1.

4. (Optional) Compress the compiled classes into a JAR file.

5. In your CLASSPATH environment variable, add the location of the JAR files or compiled Java classes.

To extract field and storable class definitions from the source BRM cloud native server:

1. To extract definitions for both fields and storable classes, add the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script:

   #!/bin/sh   
   cd /oms/sys/data/config; pin_deploy field [-cp] fieldName1 fieldName2 fieldNameN 
   cd /oms/sys/data/config; pin_deploy class [-mnscp] className1 className2 classNameN 
   exit 0;

   where:

   • fieldNameN specifies the name of the field to export.

   • classNameN specifies the name of the storable class to export.

   • -m specifies to export the storable class implementation.

   • -n specifies to export the storable class interface.

   • -s specifies to include all subclasses of specified storable class.

   • -c specifies to include field definitions for all customer-defined fields within storable classes.

   • -p specifies to include field definitions for all BRM-defined fields within storable classes.

2. In the override-values.yaml file for oc-cn-helm-chart, set ocbrm.config_jobs.run_apps to true.

3. Run the helm upgrade command to update the release:

   helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

   where:

   • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

   • OverrideValuesFile is the file name and path to your override-values.yaml file.

   • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

To import field and storable class definitions into the destination BRM server:

1. Add up the implementation definitions (for example, initial clause) of the PODL files you want to import to verify that you have enough disk space. The lines start with this text:

   SQL_STORAGE =

2. Configure BRM cloud native to do the following:

   • Run pin_deploy in verify mode to determine if there are any conflicts with existing storable class and field definitions.

   • Commit the storable class and field definitions to the BRM database.

   To do so, add the following lines to the oc-cn-helm-chart/config_scripts/loadme.sh script:

   #!/bin/sh   
   cd /oms/sys/data/config; pin_deploy verify filename.podl 
   cd /oms/sys/data/config; pin_deploy command filename.podl 
   exit 0;

   where:

   • filename is the name of the PODL file that contains your storable class or field definitions. If there are multiple PODL files, separate the file names using a space as a delimiter.

   • command is either:

     • create to preserve old storable class and field definitions that conflict with new ones

     • replace to overwrite storable class and field definitions that conflict with existing ones.

3. In the override-values.yaml file for oc-cn-helm-chart, set ocbrm.config_jobs.run_apps to true.

4. Run the helm upgrade command to update the release:

   helm upgrade BrmReleaseName oc-cn-helm-chart --values OverrideValuesFile -n BrmNameSpace

   where:

   • BrmReleaseName is the release name for oc-cn-helm-chart and is used to track this installation instance.

   • OverrideValuesFile is the file name and path to your override-values.yaml file.

   • BrmNameSpace is the namespace in which to create BRM Kubernetes objects for the BRM Helm chart.

In all cases, the utility imports the entire PODL file. Nothing from the file is loaded if the utility cannot load the entire file. For example, if it loads a storable class that includes custom fields, they must exist in the data dictionary or in the PODL file for the storable class to load.