Install WebLogic 12.2.1.4 on the Linux host. The specific patchset does not matter as long as it contains the patch referenced in "Applying the WebLogic Patch for External Systems".

To prepare the WebLogic system to run the emulator:

1. Start WebLogic server and create a domain accepting all the default settings. Do not enable JRF or any other Fusion MiddleWare capabilities for this sample. Name the domain simple.
2. Stop the WebLogic server and find the domain home for simple.
3. Edit the domain-home/config/config.xml file and delete the line: <admin-server-name>AdminServer</admin-server-name> .
4. Locate and open the samples/saf-sample/emulated-weblogic-resources/config/config_fragment.xml configuration fragment XML file in the OSM cloud native toolkit.
5. Copy the contents under the domain element and append them to the end of the domain element in the domain-home/config/config.xml file just before </domain>.

   This creates a persistent store for JMS as well as a JMS server and a SAF agent. The SAF agent is used in sending emulator responses back to the OSM cloud native instance.

6. Copy the samples/saf-sample/emulated-weblogic-resources/config/jms folder in the toolkit to <domain-home>/config. This creates a folder jms under the target config directory with the specific JMS configuration. This also creates JMS queues and SAF entities.
7. Configure the SAF system to connect to your OSM cloud native instance. The instance does not need to be up at this point, but you should have decided on a project name, instance name, and the WebLogic username and password. If you want to reuse the basic OSM instance, you should already have these ready.
   Edit the domain_home/config/jms/simple_osm_jms_module-jms.xml file and update the fields underlined in the following fragment. The password is entered as plain text and gets auto-encrypted during WLS startup:

       <saf-login-context>
           <loginURL>osm_cn_t3_url</loginURL>
           <username>osm_weblogic_username</username>
           <password-encrypted>osm_weblogic_password</password-encrypted>
       </saf-login-context>
   

   osm_cn_t3_url is:
   • If Oracle Cloud Infrastructure Load Balancer is not used: http://t3.instance.project.osm.org:30305
   • If Oracle Cloud Infrastructure Load Balancer is used: http://t3.instance.project.osm.org:80
8. Start WebLogic. At this point, if you see errors from SAF/JMS about your OSM cloud native instance, you can ignore them. These errors go away once the OSM cloud native instance is up and configured for the SAF sample.
9. When enabling cross-domain security, configure its components using Weblogic Scripting Tool (WLST) in online mode by following the steps below:
   1. Once the simple domain is up and running, start the WLST at the location $FMW_HOME/oracle_common/common/bin

      $ ./wlst.sh
       
      Initializing WebLogic Scripting Tool (WLST) ...
       
      Welcome to WebLogic Server Administration Scripting Shell
       
      Type help() for help on available commands
        
      wls:/offline>

   2. Connect to the admin server by setting values corresponding to simple domain Weblogic server.

      wls:/offline> connect('<username>','<password>','t3://<admin-server-host>:<admin-server-port>')

      Upon connecting successfully, you will see a message like the one below:

      Connecting to t3://localhost:7001 with userid weblogic ...
      Successfully connected to Admin Server "AdminServer" that belongs to domain "simple".

   3. Since this attribute is set as read-only, start an edit session and navigate to the domain for setting the cross-domain security to true. Save and activate the changes.

      wls:/simple/serverConfig/> edit()
      Location changed to edit tree.
      This is a writable tree with DomainMBean as the root.
      To make changes you will need to start an edit session via startEdit().
      For more help, use help('edit').
      You already have an edit session in progress and hence WLST will
      continue with your edit session.
        
      wls:/simple/edit/ !> startEdit()
      Starting an edit session ...
      Started edit session, be sure to save and activate your changes once you are done.
      wls:/simple/edit/ !> cd('SecurityConfiguration/simple')
      wls:/simple/edit/SecurityConfiguration/simple !> cmo.setCrossDomainSecurityEnabled(true)
      wls:/simple/edit/SecurityConfiguration/simple !> save()
      Saving all your changes ...
      Saved all your changes successfully.
      wls:/simple/edit/SecurityConfiguration/simple !> activate()
      Activating all your changes, this may take a while ...
      The edit lock associated with this edit session is released once the activation is completed.
      Activation completed

   4. To configure a cross-domain user, navigate back to the root and then to the authentication provider to create a user simple-cross-user by setting an appropriate password. Assign the user to the CrossDomainConnectors group. This credential will be used in step 4 of Preparing the OSM Cloud Native Instance, while creating the secret simple-cross-user-credentials in the OSM cloud native instance.

      wls:/simple/edit/SecurityConfiguration/simple> serverConfig()
      wls:/simple/serverConfig/> cd('SecurityConfiguration/simple/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator')
      wls:/simple/serverConfig/SecurityConfiguration/simple/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator> cmo.createUser('simple-cross-user', '<password>', 'for cross-domain security')
      wls:/simple/serverConfig/SecurityConfiguration/simple/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator> cmo.addMemberToGroup('CrossDomainConnectors', 'simple-cross-user')

   5. To configure credential mapping for cross-domain security, navigate to the credential mapper directory. Create a credential for osm-cross-user as configured in OSM cloud native. Refer to step 4 of Preparing the OSM Cloud Native Instance for more information. Replace remoteHost with the OSM domain name.

      wls:/simple/serverConfig/SecurityConfiguration/simple/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator> cd('/SecurityConfiguration/simple/Realms/myrealm/CredentialMappers/DefaultCredentialMapper')
      wls:/simple/serverConfig/SecurityConfiguration/simple/Realms/myrealm/CredentialMappers/DefaultCredentialMapper> cmo.setUserPasswordCredential('type=<remote>, protocol=cross-domain-protocol, remoteHost=<project>-<instance>', 'osm-cross-user', '<password>')
      wls:/simple/serverConfig/SecurityConfiguration/simple/Realms/myrealm/CredentialMappers/DefaultCredentialMapper> cmo.setUserPasswordCredentialMapping('type=<remote>, protocol=cross-domain-protocol, remoteHost=<project>-<instance>', 'cross-domain', 'osm-cross-user')

      Note:

      While setting the credential and mapping it, do not change the value for type. It must be <remote> as specified above.
   6. Once all the cross-domain security components are configured successfully, disconnect from the admin server and exit the script.

      wls:/simple/serverConfig/SecurityConfiguration/simple/Realms/myrealm/CredentialMappers/DefaultCredentialMapper> disconnect()
      Disconnected from weblogic server: AdminServer
      wls:/offline> exit()
       
       
      Exiting WebLogic Scripting Tool.

To prepare the OSM cloud native instance for the SAF sample:

1. Obtain a starter project specification. This can be the samples/project.yaml sample in the toolkit or you can reuse the project specification created for the basic OSM cloud native instance.
   1. Configure a UDQ (SimpleResponseQueue) to receive the response from an external WebLogic domain by replacing the following line:

      uniformDistributedQueues: {}

      with the following:

      uniformDistributedQueues:
        - name: SimpleResponseQueue
          jndiName: oracle.communications.ordermanagement.SimpleResponseQueue
          resetDeliveryCountOnForward: false
          deliveryFailureParams:
            expirationPolicy: Discard
            redeliveryLimit: 10
          deliveryParamsOverrides:
            timeToLive: -1
            priority: -1
            redeliveryDelay: 1000
            deliveryMode: 'No-Delivery'

      If uniformDistributedQueues already exists in your project.yaml file, do not create a new element. Instead, append the item SimpleResponseQueue from the above snippet to the end of the existing list of items for uniformDistributedQueues.
   2. Configure the SAF Queue (RequestQueue) by replacing the following line:

      safDestinationConfig: {}

      with the following:

      safDestinationConfig:
        - name: simple
          destinations:
            - jndiPrefix: simple.
              queues:
                - queue:
                   localJndi: RequestQueue
                   remoteJndi: RequestQueue

      The cartridge deployed for this sample uses this SAF queue to send messages to the external WebLogic domain.

      If safDestinationConfig already exists in your project.yaml file, do not create a new element. Instead, append the item simple from above to the end of the existing list of items for safDestinationConfig.

2. Obtain a starter instance specification. This can be the samples/instance.yaml sample in the toolkit or you can reuse the instance specification created for your basic OSM instance.
   1. If you start with the instance.yaml sample, you must use your experience with creating a basic OSM cloud native instance to set up the DB server, NFS for logs (optional), authentication, and so on.
   2. Configure the connection to the external OSM WebLogic domain by replacing the following line:

      safConnectionConfig: {}

      with the following:

      safConnectionConfig:
        - name: simple
          t3Url: t3://{simple_weblogic_hostname}:{simple_weblogic_port}
          secretName: simplesecret

      Replace the value of {simple_weblogic_hostname} and {simple_weblogic_port} with the hostname and port where simple WebLogic domain is installed. If safConnectionConfig already exists in your project-instance.yaml, do not create a new element. Instead, append the item simple from the above to the end of the existing list of items for safConnectionConfig.
3. Create a secret to contain the credentials for the simple WebLogic domain by running the following command. Name the secret as simpleSecret as specified in the above steps for the SAF connection and Replace the username and password with the values for the simple WebLogic domain.

   kubectl -n project create secret generic simplesecret --from-literal=username='simple_domain_weblogic_username' --from-literal=password='simple_domain_weblogic_password'

4. When enabling cross-domain security, the components of the instance must be configured via the project and instance specification:
   1. To configure your instance specification, replace the existing domainTrust configuration with the following:

      domainTrust:
        globalEnabled: false
        crossDomain:
          enabled: true
          remoteDomains:
            - name: simple
              secretName: simple-cross-user-credentials

      Create the secret simple-cross-user-credentials to contain the credentials of the cross-domain user configured for the simple WebLogic domain by running the following command. Enter the project name and password that you are using.

      kubectl create secret generic -n project simple-cross-user-credentials --from-literal=username=simple-cross-user --from-literal=password=<password>

   2. To configure your project specification, provide username for the user to be created and added to CrossDomainConnectors group in the OSM domain by replacing the existing crossDomainTrustUsers configuration with the following:

      crossDomainTrustUsers:
        - osm-cross-user

      Create the xtrust secret for configuring the user credentials for the above cross-domain trust user by running the following CNTK script:

      $ $OSM_CNTK/scripts/manage-instance-credentials.sh -p $PROJECT -i $INSTANCE create xtrust

      This user's credentials must be same as the one supplied in step 9 of Preparing the WebLogic System to Run the Emulator.

5. Bring up the OSM cloud native instance. If you are not reusing the basic OSM instance, you will have to first create all the required secrets.
6. If you used a clone of the PDB of the basic OSM cloud native instance, you must replicate the opssWF and opssWP secrets from your basic OSM instance and set rcu.db.preexisting to true in your instance specification file. Failing to do this results in your new instance not being able to process the cloned PDB.
7. Once the OSM cloud native instance is up, do the following:
   1. Log in to the OSM Orchestration UI.
   2. Go to Administer Workgroups.
   3. Choose the OSM user you will be using to inject orders and add this user to the "SimpleProvisioningRole" workgroup.
   This allows your chosen user to create orders in the SimpleProvisioning cartridge.

   Both SAF endpoints, one on simple and one in this OSM cloud native instance should now be active. You can confirm this by validating the setup.

You can submit orders with HTTP and T3 over HTTP.