IBM BPM, V8.0.1, All platforms > Install IBM BPM > IBM BPM Advanced > Install IBM BPM Advanced > On AIX > Network deployment environment > Configure profiles and create an ND environment > Create or augment ND profiles > Oracle database server > Create or augment custom profiles

Create custom profiles using PMT

You can create and federate custom profiles using PMT.

The language of pmt.sh is determined by the default language on the system. If the default language is not one of the supported languages, English is used. You can override the default language by starting pmt.sh from the command line and using the java user.language setting to replace the default language.

 INSTALL_ROOT/java/bin/java -Duser.language= locale  INSTALL_ROOT

For example, to start pmt.sh in the German language:

 INSTALL_ROOT/java/bin/java -Duser.language=de  INSTALL_ROOT/bin/ProfileManagement/startup.jar

After you start pmt.sh, decide whether to choose Typical or Advanced profile creation. Use the advanced option to:

• Assign customized values to ports, to the location of the profile, and to the names of the profile, node, host, and cell (when applicable).

• Create a system service to run the server, if your operating system and the privileges of your user account permit the creation of services.

Procedure

1. If you want to federate the custom node to a dmgr while creating the custom profile, start the dmgr.

2. Use one of the following methods to start pmt.sh.

   • Start the tool from the First steps console.

   • Run the command INSTALL_ROOT/bin/ProfileManagement/pmt.sh.

3. On the Welcome page, click Launch Profile Management Tool .

4. On the Profiles tab, click Create.

   The Environment Selection page opens in a separate window.

5. On the Environment Selection page, locate the IBM BPM Advanced configuration and expand the section. Select the profile to create and click Next.

6. If you selected Typical profile creation, skip to the Federation step.

7. Advanced: On the Profile Name and Location page...

   1. In the Profile name field, specify a unique name or accept the default value. Each profile created must have a name. When you have more than one profile, you can tell them apart at their highest level by this name.

   2. In the Profile directory field, enter the directory for the profile or use the Browse button to go to the profile directory. The directory you specify will contain the files that define the runtime environment, such as commands, configuration files, and log files. The default directory is INSTALL_ROOT/profiles/ profile_name.

   3. Select Make this profile the default to make the profile you are creating the default profile. This check box is shown only if you have an existing profile on your system.

      When a profile is the default profile, commands work automatically with it. The first profile created on a workstation is the default profile. The default profile is the default target for commands that are issued from the bin directory in the product installation root. When only one profile exists on a workstation, every command operates on that profile. If more than one profile exists, certain commands require that you specify the profile to which the command applies.

   4. From the Server runtime performance tuning setting list, select a performance tuning level appropriate for the profile you are creating. This parameter is a WebSphere Application Server parameter.

   5. Click Next. If you click Back and change the name of the profile, you might have to manually change the name on this page when it is displayed again.

8. Advanced: On the Node, Host and Cell Names page, perform the following actions for the profile you are creating:

   • In the Node name field, enter a name for the node or accept the default value. Try to keep the node name as short as possible, but ensure that node names are unique within your deployment environment.

   • In the Server name field, enter a name for the server or accept the default value.

   • In the Host name field, enter a name for the host or accept the default value.

   • In the Cell name field, enter a name for the cell or accept the default value.

   Click Next.

9. On the Federation page, choose to federate the node into the dmgr now as part of the profile creation, or at a later time and apart from profile creation If you choose to federate the node as part of the profile creation, specify the host name or IP address and SOAP port of the dmgr, and an authentication user ID and password if to be used to authenticate with the dmgr.

   Important:

   Select Federate this node later if any one of the following situations is true:

   • You plan to use this custom node as a migration target.

   • Another profile is being federated. (Node federation must be serialized.)

   • The dmgr is not running or you are not sure if it is running.

   • The dmgr has the SOAP connector disabled

   • The dmgr has not yet been augmented into a IBM BPM dmgr.

   • The dmgr is not at a release level the same or higher than the release level of the profile you are creating.

   • The dmgr does not have a JMX administrative port enabled.

   • The dmgr is re-configured to use the non-default remote method invocation (RMI) as the preferred Java™ Management Extensions (JMX) connector. (Select System administration > Deployment manager > Administration services in the administrative console of the dmgr to verify the preferred connector type.)

   
   Processing associated with federating the node as part of custom profile creation:

   • The Profile Management Tool verifies that the dmgr exists and can be contacted, and that the authentication user ID and password are valid for that dmgr (if it is secured).

   • If you attempt to federate a custom node when the dmgr is not running or is not available for other reasons, a warning box prevents you from continuing. If this warning box appears, click OK and then make different selections on the Federation page.

   Click Next.

   If you selected Typical profile creation, skip to the Database Configuration step.

10. Advanced: On the Security Certificate (Part 1) page, specify whether to create new certificates or import existing certificates.

    • To create a new default personal certificate and a new root signing certificate, select Create a new default personal certificate and Create a new root signing certificate, and click Next.

    • To import existing certificates, select Import an existing default personal certificate and Import an existing root signing personal certificate and provide the following information:

      • In the Path field, enter the directory path to the existing certificate.

      • In the Password field, enter the password for the certificate

      • In the Keystore type field, select the keystore type for the certificate you are importing.

      • In the Keystore alias field, select the keystore alias for the certificate you are importing.

      • Click Next to display the Security Certificate (Part 2) page

      When you import a personal certificate as the default personal certificate, import the root certificate that signed the personal certificate. Otherwise, pmt.sh adds the signer of the personal certificate to the trust.p12 file.

11. Advanced: On the Security Certificate (Part 2) page, verify that the certificate information is correct, and click Next to display the Port Values Assignment page.

    If you create the certificates, you can use the default values or modify them to create new certificates. The default personal certificate is valid for one year by default and is signed by the root signing certificate. The root signing certificate is a self-signed certificate that is valid for 15 years by default. The default keystore password for the root signing certificate is WebAS. Change the password. The password cannot contain any double-byte character set (DBCS) characters because certain keystore types, including PKCS12, do not support these characters. The keystore types that are supported depend on the providers in the java.security file.

    When you create either or both certificates, or import either or both certificates, the keystore files that are created are:

    • key.p12: Contains the default personal certificate.
    • trust.p12: Contains the signer certificate from the default root certificate.
    • root-key.p12: Contains the root signing certificate.
    • default-signers.p12: Contains signer certificates that are added to any new keystore file created after the server is installed and running. By default, the default root certificate signer and a DataPower signer certificate are in this keystore file.
    • deleted.p12: Holds certificates deleted with the deleteKeyStore task so that they can be recovered if needed.
    • ltpa.jceks: Contains server default Lightweight Third-Party Authentication (LTPA) keys that the servers in your environment use to communicate with each other.

    These files all have the same password when you create or import the certificates, which is either the default password, or a password that you specify. An imported certificate is added to the key.p12 file or the root-key.p12 file. If you import any certificates and the certificates do not contain the information that you want, click Back to import another certificate.

12. Advanced: On the Port Values Assignment page, verify that the ports specified for the profile are unique and click Next. The Profile Management Tool detects ports currently used by other WebSphere products and displays recommended port values that do not conflict with existing ones. If you have applications other than WebSphere ones that use specified ports, verify that the ports do not conflict. If you chose not to deploy the administrative console on the Optional Application Deployment page, the administrative console ports are not available on the Port Values Assignment page.

    Ports are recognized as being in use if the following conditions are satisfied:

    • The ports are assigned to a profile created under an installation performed by the current user.

    • The ports are currently in use.

    Although the tool validates ports when you access the Port Values Assignment page, port conflicts can still occur resulting from selections you make on subsequent Profile Management Tool pages. Ports are not assigned until profile creation completes.

    If you suspect a port conflict, you can investigate it after the profile is created. Determine the ports used during profile creation by examining the following file:

     profile_root/properties/portdef.prop

    Included in this file are the keys and values used in setting the ports. If you discover port conflicts, you can reassign ports manually. To reassign ports, see "Updating ports in existing profiles" in the WebSphere Application Server information center. Run the updatePorts.ant file through the ws_ant script detailed in this topic.

13. On the Database Configuration page, select the database used by the dmgr and confirm the location of the JDBC driver classpath files.

14. On the Profile Summary page, review the information. Click Create to create the profile or Back to change the characteristics of the profile.

15. On the Profile Complete page, review the information. To proceed to the First Steps Console, make sure that Launch First Steps Console is selected and click Finish.

What to do next

After you have finished adding custom profiles, configure the deployment environment.

Create or augment custom profiles