5 Customizing Web Services Manager

Learn how to customize Oracle Communications Billing and Revenue Management (BRM) Web Services Manager to expose your customized opcodes or support custom web services.

Topics in this document:

For information about enabling or disabling validation of input and output XML data, see "Validating Input and Output XML Data".

Setting Up Web Services Manager to Support Custom Fields in Opcodes

You can expose custom fields in BRM opcodes that are exposed by default as web services by doing the following:

  1. Add the custom field to the opcode in BRM. See "Creating Custom Fields and Storable Classes" in BRM Developer's Guide for instructions.

  2. Update the appropriate .xsd file with the new fields.

  3. Copy the updated .xsd file to the location specified by the webservices.schema.location entry in the BRM_home/apps/brm_wsm/config/Infranet.properties file.

  4. If you want to control XML validation, see "Validating Input and Output XML Data".

  5. Stop and restart Web Services Manager.

Setting Up Web Services Manager to Support Unexposed Opcodes for XML-Element Services

You can expose BRM opcodes that are not exposed by default as web services by completing this procedure.

See "About WSDL Files and BRM Opcodes" for information about the opcodes that are exposed by default.

To enable Web Services Manager to support these opcodes:

  1. Generate the XSD file for your system. See "Generating the Schema Files for Your System" for instructions.

  2. Copy the generated XSD file to the location specified in webservices.schema.location in the BRM_home/apps/brm_wsm/config/Infranet.properties file.

  3. Create a WSDL file for the web service. See "Generating WSDL Files for Web Services" in BRM JCA Resource Adapter.

  4. Generate the sun-jaxws.xml file using one of the following endpoints:

    • /configurations/endpoints/default (to get the default deployment descriptor)

    • /configurations/endpoints (to get a custom deployment descriptor, if already deployed)

  5. Update the corresponding <endpoint> tag in the generated sun-jaxws.xml file for your implementation so that it points to your customized endpoint.

    • To expose the opcode under an existing service group:

      1. Update only the wsdl attribute to point to the path of the WSDL file, which will be placed inside a JAR file later in this procedure. 

        <endpoint name="endpointName"
    implementation="pathToClass"
    url-pattern="urlPattern"
    wsdl="WEB-INF/wsdl/customDir/customWsdl"/>

        where:

        • endpointName is the logical name of the endpoint for the web service.

        • pathToClass is the fully qualified name of the implementation class.

        • urlPattern is the URL pattern to access the web service.

        • customDir is a custom directory created to avoid conflicts with the standard Web Services Manager WSDL files. Ensure that your custom WSDL is located in this directory.

        • customWsdl is the name of the WSDL file. Ensure that you add the same custom WSDL file to the JAR file later in this procedure.

        For example:

        <endpoint name="JAXWS_BRMCustomService"
    implementation="com.oracle.communications.brm.wsm.jaxws.services.cust.BRMCustomServicePttImpl"
    url-pattern="/jaxws/BRMCustomService"
    wsdl="WEB-INF/wsdl/customDir/BRMCustomServices_v2.wsdl"/>

      2. Create a JAR file that contains your WSDL file and your edited sun-jaxws.xml file in the following structure:

        • WEB-INF/wsdl/customDir/customWsdl

        • sunjaxwsPath/sun-jaxws.xml

        where sunjaxwsPath is the path to the sun-jaxws.xml you created during this procedure.

    • To expose the opcode under a new service group:

      1. Generate the web service implementation class. See "Generating the Web Service Implementation Class for XML Element Services".

      2. Generate the sun-jaxws.xml file and add the new endpoint to it. See "Configuring XML-Element Service Endpoints".

  6. Update the Infranet.properties file with the following new values: 

    webservices.descriptor=sunjaxwsPath/sun-jaxws.xml
webservices.loadcustomschema=true

  7. Set the BRM_WSM_CLASSPATH_EXT environment variable to the full path of the JAR file you created.

  8. Stop and restart the Web Services Manager. See "Starting and Stopping Web Services Manager".

Generating the Web Service Implementation Class for XML Element Services

To generate the web service implementation class for your XML-element services:

  1. Create an implementation class for your new web service.

    The following shows a sample implementation class. Ensure that you update packageName, ServiceName, PortName, ServiceClassName, and BindingSOAPVersion with your custom values. 

    package PackageName;

// Copyright (c) 2024, 2026, Oracle and/or its affiliates.

import java.util.List;
import java.util.logging.Logger;
import java.util.logging.Level;
import java.util.concurrent.ConcurrentHashMap;
import java.time.Duration;

import io.helidon.service.registry.Services;
import io.helidon.metrics.api.MeterRegistry;
import io.helidon.metrics.api.Metrics;
import io.helidon.metrics.api.Timer;
import io.helidon.metrics.api.Tag;
import io.helidon.tracing.Span;

import jakarta.annotation.Resource;
import jakarta.jws.HandlerChain;
import jakarta.jws.soap.SOAPBinding;
import jakarta.xml.ws.Provider;
import jakarta.xml.ws.ServiceMode;
import jakarta.xml.ws.BindingType;
import jakarta.xml.ws.WebServiceContext;
import jakarta.xml.ws.WebServiceProvider;
import jakarta.xml.ws.soap.SOAPFaultException;
import jakarta.xml.soap.SOAPMessage;
import jakarta.xml.soap.SOAPException;
import jakarta.xml.soap.SOAPElement;
import jakarta.xml.soap.SOAPFactory;
import jakarta.xml.soap.Detail;
import jakarta.xml.soap.SOAPFault;
import jakarta.xml.soap.SOAPConstants;

import javax.xml.namespace.QName;

import org.w3c.dom.Document;

import com.portal.pcm.DeterminateException;
import com.portal.pcm.EBufException;
import com.oracle.communications.brm.wsm.jaxws.ApiRequestProcessor;
import com.oracle.communications.brm.wsm.utils.WebServicesUtilities;
import com.oracle.communications.brm.wsm.utils.TracerHandler;
import com.oracle.communications.brm.wsm.utils.SOAPFaultResponse;
import com.oracle.communications.brm.wsm.utils.ApplicationException;

@WebServiceProvider(
   targetNamespace = "http://xmlns.oracle.com/BRM/schemas/BusinessOpcodes",
   serviceName = "ServiceName",
   portName = "PortName"
)
@ServiceMode(value = jakarta.xml.ws.Service.Mode.MESSAGE)
@SOAPBinding(
   style = SOAPBinding.Style.DOCUMENT,
   parameterStyle = SOAPBinding.ParameterStyle.BARE
)
@BindingType(jakarta.xml.ws.soap.SOAPBinding.BindingSOAPVersion)
@HandlerChain(file = "handler-chain.xml")
public class ServiceClassName implements ProviderSOAPMessage {
   private static Logger m_logger =
      Logger.getLogger(ServiceClassName.class.getName());

   private final MeterRegistry registry = Services.get(MeterRegistry.class);

   private final Tag successTag = Tag.create("status", "success");
   private final Tag failTag = Tag.create("status", "fail");

   private final ConcurrentHashMap<Integer, Timer> successResponseTimerMap =
      new ConcurrentHashMap<Integer, Timer>();
   private final ConcurrentHashMap<Integer, Timer> failedResponseTimerMap =
      new ConcurrentHashMap<Integer, Timer>();

   @Override
   public SOAPMessage invoke(SOAPMessage request) {
      m_logger.entering(
         ServiceClassName.class.getName(),
         "Starting invoke method execution for request"
      );

      Span span = TracerHandler.startSpan(
         null,
         ServiceClassName.class.getName() + "." + "invoke"
      );
      Exception spanException = null;

      String opcodeName = null;
      String soapVersion = null;
      String soapNamespaceUri = null;
      int opcodeNumber = -1;
      long startTime = System.nanoTime();
      SOAPMessage response = null;
      Timer currentTimer;

      try {
         // Determining SOAP request protocol version (1.1 or 1.2)
         soapNamespaceUri =
            request.getSOAPPart().getEnvelope().getNamespaceURI();

         if (SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE.equals(soapNamespaceUri)) {
            soapVersion = SOAPConstants.SOAP_1_1_PROTOCOL;
         } else if (SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE.equals(soapNamespaceUri)) {
            soapVersion = SOAPConstants.SOAP_1_2_PROTOCOL;
         } else {
            soapVersion = SOAPConstants.DEFAULT_SOAP_PROTOCOL;
            soapNamespaceUri = SOAPConstants.URI_NS_SOAP_ENVELOPE;
         }

         m_logger.log(
            Level.FINEST,
            "SOAP Protocol Version: " + soapVersion
               + ", SOAP Namespace URI: " + soapNamespaceUri
         );

         Document reqDoc =
            request.getSOAPBody().extractContentAsDocument();

         opcodeName =
            WebServicesUtilities.getOpcodeName(span.context(), reqDoc);
         opcodeNumber =
            WebServicesUtilities.getOpcode(span.context(), opcodeName);

         m_logger.log(
            Level.FINEST,
            "Opcode name obtained from request payload: " + opcodeName
         );

         if (!successResponseTimerMap.containsKey(opcodeNumber)) {
            m_logger.log(
               Level.FINEST,
               "Initializing success & failure metric timers"
            );

            Tag apiTag = Tag.create("api", opcodeName);

            successResponseTimerMap.put(
               opcodeNumber,
               registry.getOrCreate(
                  Timer.builder("http_request_duration")
                     .tags(List.of(apiTag, successTag))
               )
            );

            failedResponseTimerMap.put(
               opcodeNumber,
               registry.getOrCreate(
                  Timer.builder("http_request_duration")
                     .tags(List.of(apiTag, failTag))
               )
            );
         }

         ApiRequestProcessor processor = new ApiRequestProcessor();

         response = processor.processApiRequest(
            span.context(),
            reqDoc,
            opcodeName,
            opcodeNumber,
            soapVersion,
            soapNamespaceUri
         );

         currentTimer = successResponseTimerMap.get(opcodeNumber);
         currentTimer.record(
            Duration.ofNanos(System.nanoTime() - startTime)
         );
      } catch (ApplicationException e) {
         spanException = e;

         if (opcodeNumber != -1) {
            currentTimer = failedResponseTimerMap.get(opcodeNumber);
            currentTimer.record(
               Duration.ofNanos(System.nanoTime() - startTime)
            );
         }

         throw SOAPFaultResponse.createErrorResponse(
            e,
            soapVersion,
            soapNamespaceUri
         );
      } catch (SOAPException ex) {
         spanException = ex;

         if (opcodeNumber != -1) {
            currentTimer = failedResponseTimerMap.get(opcodeNumber);
            currentTimer.record(
               Duration.ofNanos(System.nanoTime() - startTime)
            );
         }

         throw SOAPFaultResponse.createErrorResponse(
            new ApplicationException(
               ex,
               ApplicationException.SERVER_EXCEPTION
            ),
            soapVersion,
            soapNamespaceUri
         );
      } finally {
         TracerHandler.endSpan(span, spanException);
         m_logger.exiting(
            ServiceClassName.class.getName(),
            "Completed invoke method execution for request"
         );
      }

      return response;
   }
}

  2. Create the BRMCustomServicePttImpl.java file and compile it using the following command: 

    javac -d . -cp ".:$PIN_HOME/jars/*" packageName/BRMCustomServicePttImpl.java

    where packageName is the package name configured in your implementation class.

Configuring XML-Element Service Endpoints

To configure an XML-element service endpoint and package its required implementation and WSDL files:

  1. Generate the sun-jaxws.xml file using one of the following endpoints:

    • /configurations/endpoints/default (to get the default deployment descriptor)

    • /configurations/endpoints (to get a custom deployment descriptor if already deployed)

  2. Add the new endpoint to the generated sun-jaxws.xml file for your implementation: 

    <endpoint name="endpointName"
    implementation="pathToClass"
    url-pattern="urlPattern"
    wsdl="WEB-INF/wsdl/customDir/customWsdl"/>

    where:

    • endpointName is the logical name of the endpoint for the web service.

    • pathToClass is the fully qualified name of the implementation class.

    • urlPattern is the URL pattern to access the web service.

    • customDir is a custom directory created to avoid conflicts with the standard Web Services Manager WSDL files. Ensure that your custom WSDL is located in this directory.

    • customWsdl is the name of the WSDL file you created. Ensure that you add the same custom WSDL file to the JAR file later in this procedure.

    For example:

    <endpoint name="JAXWS_BRMCustomService"
    implementation="CustomPackage.BRMCustomServicePttImpl"
    url-pattern="/jaxws/BRMCustomService"
    wsdl="WEB-INF/wsdl/customDir/BRMCustomServices_v2.wsdl"/>

  3. Create a JAR file that contains your implementation class, its WSDL file, and your edited sun-jaxws.xml file in the following structure:

    • WEB-INF/wsdl/customDir/customWsdl

    • sunjaxwsPath/sun-jaxws.xml

    • packageName/BRMCustomServicePttImpl.class

    where:

    • customDir is the custom folder used to distinguish your custom WSDL from the standard WSDL files.

    • customWsdl is the name of your WSDL file.

    • sunjaxwsPath is the path to the sun-jaxws.xml you created.

    • packageName is the package name configured in your implementation class.

Setting Up Web Services Manager to Support Unexposed Opcodes for XML-String Services

You can expose BRM opcodes that are not exposed by default as web services by completing this procedure.

See "About WSDL Files and BRM Opcodes" for information about the opcodes that are exposed by default.

To enable Web Services Manager to support these opcodes:

  1. To expose your new opcodes under an existing service group:

    1. Create a service implementation class to include the opcodes that are not already exposed by extending the available implementation class.

      package com.oracle.services;

import com.oracle.communications.brm.wsm.jaxws_str.BRMCust;
import com.oracle.communications.brm.wsm.utils.ApplicationException;
import com.oracle.communications.brm.wsm.utils.OpcodeCaller;
import com.oracle.communications.brm.wsm.utils.SOAPFaultResponse;

import jakarta.jws.HandlerChain;
import jakarta.jws.WebMethod;
import jakarta.jws.WebParam;
import jakarta.jws.WebResult;
import jakarta.jws.WebService;
import jakarta.jws.soap.SOAPBinding;
import jakarta.xml.soap.SOAPConstants;

@WebService(
   name = "ExtendedBRMCustService",
   portName = "ExtendedBRMCustService_ptt",
   targetNamespace = "http://xmlns.oracle.com/BRM/schemas/BusinessOpcodes/"
)
@SOAPBinding(style = SOAPBinding.Style.RPC)
@HandlerChain(file = "handler-chain.xml")
public class ExtendedBRMCust extends BRMCust {

   @WebMethod(operationName = "pcmOpCustValidateCustomer")
   @WebResult(name = "PCM_OP_CUST_VALIDATE_CUSTOMER_response")
   public String validateCustomer(
      @WebParam(name = "flags") int flag,
      @WebParam(name = "PCM_OP_CUST_VALIDATE_CUSTOMER_request") String inFlist
   ) {
      OpcodeCaller opcodeCaller = new OpcodeCaller();

      try {
         return opcodeCaller.opcodeWithFlags(
            "PCM_OP_CUST_VALIDATE_CUSTOMER",
            flag,
            inFlist,
            "PCM_OP_CUST_VALIDATE_CUSTOMER.xsd"
         );
      } catch (ApplicationException ex) {
         throw SOAPFaultResponse.createErrorResponse(
            ex,
            SOAPConstants.SOAP_1_1_PROTOCOL,
            SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE
         );
      }
   }
}

    2. Compile the implementation class using the following command:

      javac -d . -cp ".:$PIN_HOME/jars/*" packageName/ExtendedBRMCust.java

      where packageName is the package name configured in your implementation class.

    3. Generate the sun-jaxws.xml file using one of the following endpoints:

      • /configurations/endpoints/default (to get the default deployment descriptor)

      • /configurations/endpoints (to get a custom deployment descriptor, if already deployed)

    4. Update the endpoint in the generated sun-jaxws.xml file for your implementation: 

      <endpoint name="endpointName"
   implementation="pathToClass"
   url-pattern="urlPattern"/>

      where:

      • endpointName is the logical name of the endpoint for the web service.

      • pathToClass is the fully qualified name of the implementation class.

      • urlPattern is the URL pattern to access the web service.

      For example:

      <endpoint
   name="JAXWS_STR_BRMCustomService"
   implementation="CustomPackage.ExtendedBRMCust"
   url-pattern="/jaxws_str/BRMCustomService"/>

    5. Create a JAR file that contains your implementation class and your edited sun-jaxws.xml file in the following structure:

      • sunjaxwsPath/sun-jaxws.xml

      • packageName/ExtendedBRMCust.class

      where sunjaxwsPath is the path to the sun-jaxws.xml file you created, and packageName is the package name configured in your implementation class.

  2. To expose your new opcodes under a new service group, create a new service class and add web methods by doing the following:

  3. Update the Infranet.properties file with the following new values: 

    webservices.descriptor=sunjaxwsPath/sun-jaxws.xml

    where sunjaxwsPath is the path to the sun-jaxws.xml you created during this procedure.

  4. Add the full path to the JAR file that you created to the BRM_WSM_CLASSPATH_EXT environment variable.

  5. Stop and restart the Web Services Manager. See "Starting and Stopping Web Services Manager".

Generating the Web Service Implementation Class for XML-String Services

To generate the web service implementation class for the custom service, do the following:

  1. Create an implementation class for your new web service.

    The following shows a sample implementation class. Replace packageName with your custom value. You can add multiple web methods to support multiple opcodes. 

    package packageName;

// Copyright (c) 2025, Oracle and/or its affiliates.

import com.oracle.communications.brm.wsm.utils.ApplicationException;
import com.oracle.communications.brm.wsm.utils.OpcodeCaller;
import com.oracle.communications.brm.wsm.utils.SOAPFaultResponse;

import jakarta.jws.HandlerChain;
import jakarta.jws.WebMethod;
import jakarta.jws.WebParam;
import jakarta.jws.WebResult;
import jakarta.jws.WebService;
import jakarta.jws.soap.SOAPBinding;
import jakarta.xml.soap.SOAPConstants;

/**
 * Class that implements the OOB Infranet CUST Web Service.
 *
 * <p>This class delegates all functionality related to communicating with
 * Infranet and calling opcodes to {@code OpcodeCaller}. This allows
 * flexibility in reimplementing the web service for a different application
 * server. For example, the new implementation can call the
 * {@code OpcodeCaller} utility functions.
 *
 * <p>CUSTOM_OP_GENERIC<br>
 */
@WebService(
   name = "BRMCustomService",
   targetNamespace = "http://xmlns.oracle.com/BRM/schemas/BusinessOpcodes/",
   portName = "BRMCustomService_ptt"
)
@SOAPBinding(style = SOAPBinding.Style.RPC)
@HandlerChain(file = "handler-chain.xml")
public class BRMCustomInfra {

   @WebMethod(operationName = "customOpGeneric")
   @WebResult(name = "CUSTOM_OP_GENERIC_response")
   public String customGeneric(
      @WebParam(name = "flags") int flag,
      @WebParam(name = "CUSTOM_OP_GENERIC_request") String inFlist
   ) {
      OpcodeCaller opcodeCaller = new OpcodeCaller();

      try {
         return opcodeCaller.opcodeWithFlags(
            "CUSTOM_OP_GENERIC",
            flag,
            inFlist,
            "CUSTOM_OP_GENERIC.xsd"
         );
      } catch (ApplicationException ex) {
         throw SOAPFaultResponse.createErrorResponse(
            ex,
            SOAPConstants.SOAP_1_1_PROTOCOL,
            SOAPConstants.URI_NS_SOAP_1_1_ENVELOPE
         );
      }
   }
}

  2. Compile the implementation class using the following command:

    javac -d . -cp ".:$PIN_HOME/jars/*" packageName/BRMCustomInfra.java

  3. Generate the sun-jaxws.xml file using one of the following endpoints:

    • /configurations/endpoints/default (to use the default deployment descriptor)

    • /configurations/endpoints (to use a custom deployment descriptor)

  4. Add the new endpoint in the generated sun-jaxws.xml file for your implementation: 

    <endpoint name="endpointName"
    implementation="pathToClass"
    url-pattern="urlPattern"/>

    where:

    • endpointName is the logical name of the endpoint for the web service.

    • pathToClass is the fully qualified name of the implementation class.

    • urlPattern is the URL pattern to access the web service.

    For example:

    <endpoint
    name="JAXWS_STR_BRMCustomService"
    implementation="CustomPackage.BRMCustomInfra"
    url-pattern="/jaxws_str/BRMCustomService"/>

  5. Create a JAR file that contains your implementation class and your edited sun-jaxws.xml file in the following structure:

    • sunjaxwsPath/sun-jaxws.xml

    • packageName/BRMCustomInfra.class

    where:

    • sunjaxwsPath is the path to the sun-jaxws.xml you created.

    • packageName is the package name configured in your implementation class.

Configuring XML-String Service Endpoints

To configure an XML-string service endpoint and package its required implementation and WSDL files:

  1. Generate the sun-jaxws.xml file using one of the following endpoints:

    • /configurations/endpoints/default (to get the default deployment descriptor)

    • /configurations/endpoints (to get a custom deployment descriptor if already deployed)

  2. Add the new endpoint to the generated sun-jaxws.xml file for your implementation: 

    <endpoint name="endpointName"
    implementation="pathToClass"
    url-pattern="urlPattern"/>

    where:

    • endpointName is the logical name of the new endpoint for the web service.

    • pathToClass is the fully qualified name of the implementation class.

    • urlPattern is the URL pattern to access the web service.

    For example:

    <endpoint
    name="JAXWS_STR_BRMCustomService"
    implementation="CustomPackage.BRMCustomInfra"
    url-pattern="/jaxws_str/BRMCustomService" />

  3. Create a JAR file that contains your implementation class and your edited sun-jaxws.xml file in the following structure:

    • sunjaxwsPath/sun-jaxws.xml

    • packageName/BRMCustomInfra.class

    where:

    • sunjaxwsPath is the path to the sun-jaxws.xml you created during this procedure.

    • packageName is the package name configured in your implementation class.

Setting Up Web Services Manager to Support Custom Opcodes

You can expose your custom opcodes as web services by following the procedures below.

See "About WSDL Files and BRM Opcodes" for more information about the opcodes that are exposed by default.

See the following sections for details of how to support custom opcodes:

Supporting Custom Opcodes for XML-Element Services

To enable Web Services Manager to support these opcodes for web services that expect an XML element payload:

  1. Generate the XSD file for your system. See "Generating the Schema Files for Your System" for instructions.

  2. Copy the generated XSD file to the location specified in webservices.schema.location in the BRM_home/apps/brm_wsm/config/Infranet.properties file.

  3. Create a WSDL file for the web service. See "Generating WSDL Files for Web Services" in BRM JCA Resource Adapter.

  4. Generate the CustomFields.jar file. See "Making Custom Fields Available to Web Services Manager".

  5. Generate the web service implementation class. See "Generating the Web Service Implementation Class for XML Element Services".

  6. Generate the sun-jaxws.xml file and add the new endpoint to it. See "Configuring XML-Element Service Endpoints".

  7. Update the Infranet.properties file with the following new values: 

    webservices.descriptor=sunjaxwsPath/sun-jaxws.xml
webservices.loadcustomschema=true
infranet.custom.field.package=CustomOp_package

    where:

    • sunjaxwsPath is the path to the sun-jaxws.xml you created during this procedure.

    • package is the Java package name that contains the CustomOp class. For example, com.portal.classFiles.

  8. Update the BRM_WSM_CLASSPATH_EXT environment variable to include the full paths to both CustomFields.jar and the JAR file you created in step 6.

  9. Stop and restart the Web Services Manager. See "Starting and Stopping Web Services Manager".

Supporting Custom Opcodes for XML-String Services

To enable Web Services Manager to support these opcodes for the web services that expect an XML string payload:

  1. Generate the CustomFields.jar file. See "Making Custom Fields Available to Web Services Manager".

  2. See "Generating the Web Service Implementation Class for XML-String Services".

  3. See "Configuring XML-String Service Endpoints".

  4. Update the Infranet.properties file with the following new values: 

    webservices.descriptor=sunjaxwsPath/sun-jaxws.xml

    where sunjaxwsPath is the path to the sun-jaxws.xml you created during this procedure.

  5. Add the full paths of the CustomFields.jar file and the JAR file you created to the BRM_WSM_CLASSPATH_EXT environment variable.

  6. Stop and restart the Web Services Manager. See "Starting and Stopping Web Services Manager" for more information.

Making Custom Fields Available to Web Services Manager

To make custom fields available to Web Services Manager:

  1. Create a CustomOp.java file by doing one of the following:

    • Manually create the CustomOp.java file.

    • Run the parse_custom_ops_fields script by entering the following command: 

      parse_custom_ops_fields -L pcmjava -I input -O output -P java_package

      where:

      • input is the header file you create for your custom opcodes and fields.

      • output is the memory-mapped file or directory for the output of the script. output must be a directory having some correspondence with the Java package. For example, if java_package is in com.portal.classFiles, output must be f:/mysource/com/portal/classFiles.

      • java_package is the Java package in which to put the generated classes.

      For more information, see "parse_custom_ops_fields" in BRM Developer's Guide.

  2. Verify that the CustomOp.java file contains the following:

    • The mapping between opcode names and opcode numbers for all the custom opcodes in the file.

      Note:

      Verify that the mapping includes the full name of each opcode. If any opcode name is truncated, replace the truncated name with the full name.

    • The opToString method, which converts opcode numbers to opcode names.

    • The stringToOp method, which converts opcode names to opcode numbers.

    The following is a sample CustomOp.java file: 

    public class CustomOp {

   public static final int CUSTOM_OP_ACT_INFO = 100000;
   public static final int CUSTOM_OP_READ_ACT_PRODUCT = 100001;

   public static String opToString(int op) {
      try {
         java.lang.reflect.Field[] flds = CustomOp.class.getFields();

         for (int i = 0; i < flds.length; i++) {
            try {
               int val = flds[i].getInt(null);

               if (val == op) {
                  return flds[i].getName();
               }
            } catch (IllegalAccessException e) {
               continue;
            } catch (IllegalArgumentException e) {
               continue;
            }
         }
      } catch (SecurityException e) {
      }

      return null;
   }

   public static int stringToOp(String op) {
      try {
         java.lang.reflect.Field[] flds = CustomOp.class.getFields();

         for (int i = 0; i < flds.length; i++) {
            try {
               String name = flds[i].getName();

               if (name.equals(op)) {
                  return flds[i].getInt(null);
               }
            } catch (IllegalAccessException e) {
               continue;
            } catch (IllegalArgumentException e) {
               continue;
            }
         }
      } catch (SecurityException e) {
      }

      return -1;
   }
}

  3. Compile the CustomOp.java file into the CustomOp.class file by entering the following command: 

    javac -d . path/CustomOp.java

    For example:

    javac -d . com/portal/classFiles/CustomOp.java

  4. Package the CustomOp.class file into the CustomFields.jar file by entering the following command: 

    jar -cvf CustomFields.jar path/CustomOp.class

    For example:

    jar -cvf CustomFields.jar com/portal/classFiles/CustomOp.class

  5. Make the CustomFields.jar file available to Web Services Manager by doing the following:

    1. Copy CustomFields.jar to a directory that Web Services Manager can access. In this procedure, this directory is referred to as CustJarLoc.

    2. Open the BRM_home/apps/brm_wsm/config/Infranet.properties file in a text editor.

    3. Add or modify the following entry:

      infranet.custom.field.package = package

      where package is the name of the package that contains the CustomOp.java file; for example, com.portal.classFiles.

    4. Add all the custom fields to the Infranet.properties file. For example, if you created the custom_fld_usage_id field and the enum value for the custom_fld_usage_id field is 10001, add the following entry: 

      infranet.custom.field.10001=custom_fld_usage_id

    5. Save and close the file.

    6. Add the full path to CustJarLoc/CustomFields.jar to the BRM_WSM_CLASSPATH_EXT environment variable.

    7. Stop and restart the Web Services Manager. See "Starting and Stopping Web Services Manager" for more information.

Generating the Schema Files for Your System

Web Services Manager uses schema files to validate data it sends to or receives from BRM.

To generate the schema files for your system, do the following:

  1. If you modified any opcodes, generate schemas for the opcodes in your BRM system. See "Generating the Schema for an Existing Opcode".

  2. Generate schemas for the storable classes and subclasses in your BRM system. See "Generating the Schema for Your Storable Classes and Subclasses" in BRM JCA Resource Adapter.

  3. In your opcode schema files, specify the location of your storable class schema files. See "Specifying the Location of the Storable Class Schema Files in the Opcode Schema Files" in BRM JCA Resource Adapter.

    Note:

    After generating the opcode and storable class schema files, copy the schema files to a location that is accessible to the Web Services Manager. Ensure that the schema-file location matches the location specified in the include section of the opcode schema files and in the opcode schema InteractionSpec attribute in the WSDL files. See "Specifying the Location of the Storable Class Schema Files in the Opcode Schema Files" and "Generating the WSDL Files for Your System" in BRM JCA Resource Adapter.