1. Deploying Siebel CRM Containers on Kubernetes using Siebel Cloud Manager
  2. Deploying Siebel CRM on OCI

Deploying Siebel CRM on OCI

After you have performed all the prerequisite tasks, you can use SCM to deploy Siebel CRM on OCI. To do this, you prepare a suitable payload and then you execute this payload on SCM.

This topic contains the following information:

Related Topics

Customizing Configurations Prior to Greenfield Deployment

Making Incremental Changes to Your Siebel CRM Deployment on OCI

Overview of Siebel CRM Deployment Steps using Siebel Cloud Manager

You can deploy Siebel CRM using SCM by creating a deployment payload and submitting it using the environment API. Payload execution results in the execution of various stages necessary for Siebel CRM deployment by SCM. The execution flow depends on whether the "Use existing resources" option was selected or not during SCM stack creation.

The term "BYO" stands for "Bring Your Own" and is indicative of existing resources at the disposal of the user. For example, BYOD stands for "Bring Your Own Database".

Siebel CRM applications can be deployed using SCM in different ways based on the type of infrastructure information provided in the payload:

  1. You bring all resources (Fully BYOR): If you select "Use existing resource" during SCM provisioning, you must provide the details of all the resources such as existing mount target, file system, OKE, database in the payload that the SCM instance will use to create Siebel CRM deployment(s).

  2. SCM creates resources:

    1. All infra resources: If you do not select "Use existing resource" during SCM provisioning, SCM creates and configures all the required infrastructure resources for a Siebel CRM deployment, such as database, OKE, mount target, file system, and so on.
    2. All infra resources except database: If you do not select "Use existing resource" during SCM provisioning, user can still provide information of an existing database in the payload. SCM creates all other infra resources (mount target, file system, OKE etc.) for Siebel CRM deployment. You must make sure that the database can be connected from SCM and OKE.

After the SCM installation is completed, you can invoke the payload with the necessary information to start the deployment process of Siebel CRM and monitor the deployment stages using the REST API calls. For more details, see Checking the Status of a Requested Environment.

Notes on Authorization Information

The auth_info section in the payload is:

  • Mandatory when you select "Use existing resources" during SCM stack creation, as SCM doesn’t modify anything in the database when you choose the BYOD option.
  • Optional for an SCM provisioned environment, which means you didn’t select the "Use existing resources" option during SCM stack creation. If values are not provided, default values are assigned.

The required details in auth_info are:

  • admin_user_name and admin_user_password:

    The Siebel CRM administrator username and password is required for configuring Siebel CRM topology.

  • default_user_password:

    The default user password which is used for logging in the rest of the users, when user info is exported, and made available in the lifted artifacts.

  • table_owner_user and table_owner_password:

    The schema name and password which is the owner for all Siebel CRM tables, the password is required to execute postinstalldb process during update deployments.

  • anonymous_user_password:

    The password used for connecting the anonymous user to the database and provided in Siebel CRM configuration.

Notes on BYO-VCN (Virtual Cloud Network)

BYO-VCN feature allows you use your own VCN in OCI. This provides significant flexibility in setting up networking components like VCN, subnet, Internet Gateway, Service Gateway, NAT gateway and so on to launch the SCM instance and subsequently the Siebel CRM environment. This helps you ensure compliance with your specific network topology and security requirements.

Existing VCN can be used for SCM provisioning and/or during Siebel CRM environment provisioning.

During SCM provisioning, if the "Use existingVCN" option is:

  • Selected, SCM will not create a VCN. This option allows:

    • Selection of subnets for the SCM instance, mount target, resources (OKE, file system, database) for Siebel CRM environment provisioning.
    • Optionally, using an existing database (see Notes on BYOD section) which can be in the same or different user specified VCN where other resources like OKE, file system are created.

  • Not selected, then:

    • SCM will create a VCN. SCM instance, mount target, other resources (OKE, file system, database) for Siebel CRM deployment will be created in that VCN (that is, in this case, SCM stack and Siebel CRM will be in the same VCN).
    • Optionally, an existing VCN can still be used only for Siebel CRM environment provisioning (which means, the SCM instance and Mount Target can be in different VCNs where Siebel CRM environment will be created in).
    • You can still use an existing database (see Notes on BYOD section) which can be in the same or different user specified VCNs where other resources like OKE, file system for Siebel CRM deployment are created in.

Effectively, regardless of "Use existing VCN" option chosen, there is flexibility regarding using existing VCNs for Siebel CRM deployment resources (OKE, file system) and database.

You must ensure that the following permissions/access OCI policy requirements are met:

Notes on BYO-FSS (File System Service)

BYO file system allows users to use an existing file system and mount target (exports for the file system) during the provisioning of Siebel CRM environment. This will enable you to use your existing Siebel CRM file systems on NFS shares with Siebel CRM deployed in Kubernetes using SCM, without shifting the file system content. Alternatively, if you are not relying on OCI file system services, you can use an existing NFS share to migrate the lifted Siebel CRM file system.

Scenarios of shifting the file system:

  1. When you set the shift_siebel_fs key to false, make sure the NFS share specified in the payload contains a valid Siebel CRM file system. The system checks that the required Siebel CRM directories exist, but it does not perform any other validation. You must ensure that you use the correct NFS shares.
    • att
    • atttmp
    • cms
    • eim
    • Marketing
    • red
    • ssp
  2. When you do not set the shift_siebel_fs key, then the value defaults to true and shifts the file systems. For lift-and-shift use case, make sure that the lift bucket includes all required file system artifacts.

    The provided file system must have a directory structure as follows:

    MOUNT_TARGET_IP:/EXPORT_PATH e.g. 10.0.0.1:/siebfs0

    In the siebfs0 path it is expected to contain a valid Siebel CRM file system as per the directory structure given above.

    You can even provide multiple mount targets for different file systems. The parameters involved are: mounttarget_exports, siebfs_mt_export_paths, and zookeeper_mt_export_path. For more information, see Payload Parameters for Siebel CRM Deployment.

Notes on BYO Kubernetes

Bring your own Kubernetes refers to the concept of using your own Kubernetes clusters for Siebel CRM provisioning rather than SCM creating managed OKE cluster.

Choosing your own Kubernetes can provide significant benefits in terms of customization, cost management, security, performance, avoiding vendor lock-in, innovation and skill development. However, it also requires higher levels of expertise and operational overhead compared to utilizing SCM creating managed OKE cluster. Organizations should weigh these factors carefully based on specific needs and capabilities before deciding to go with bring your own Kubernetes.

Note: Currently, SCM supports only managed nodes for OKE. You are responsible for upgrading Kubernetes on managed nodes and for managing cluster capacity.

  • Customization and Control: With Bring your own Kubernetes, you have full control over your Kubernetes cluster, including control planes and worker nodes. This allows for more granular customization as well as optimization tailored to specific requirements.

  • Cost Management: BYO Kubernetes can be more cost-effective in certain scenarios, especially if you have an existing infrastructure setup with all network configurations or need to run a large number of clusters. Managed OKE often come up with additional costs for convenience and support they provide.

    You can optimize resource allocation and scaling policies to match workload needs, potentially reducing unnecessary expenses.

  • Security and Compliance: For organizations with strict data sovereignty requirements, managing own Kubernetes clusters ensures that data remains within your control and complies with company's regulations.

    You can implement custom security measures to your cluster, such as network policies, access controls, encryption standards that meet organization's specific compliance and security needs.

  • Performance and Reliability: You can design and implement your own high availability and disaster recovery strategies tailored to your infrastructure and business requirements.

  • Avoiding vendor lock-in: BYO Kubernetes allows you to avoid vendor lock-in by maintaining the flexibility to move your workloads across different cloud providers or on-premises environments without being tied to specific vendor's managed Kubernetes service.

When you select the "Use existing resource" option during SCM provisioning, SCM uses the cluster you provide instead of creating a new one. Therefore, if you want SCM to use your Kubernetes cluster during the Siebel CRM environment setup through REST API POST, use one the following cluster options:

  • BYO OKE - Bring your own Oracle Kubernetes Engine (OKE) option allows you to use an existing OKE cluster for Siebel CRM deployment.
  • BYO OCNE - Bring your own Oracle Cloud Native Environment (OCNE) option lets you to leverage your own OCNE cluster for Siebel CRM deployment.
  • BYO Other - Bring your own Other option enables you to use any other CNCF compliant Kubernetes cluster for Siebel CRM deployment.

You must ensure that your cluster adheres to the following rules else the execution workflow will fail during resource state validation stage:

  • The Kubernetes cluster should not contain namespaces such as <env_name> before deployment, as these namespaces will be used during Siebel CRM environment provisioning.
  • At least one node should be in Active state.
  • The Kubernetes cluster should be accessible from the SCM instance with required polices and VCN peering, if necessary, should be configured before deployment.

Notes on OKE (Oracle Container Engine for Kubernetes)

To use your own OKE cluster during Siebel CRM environment provisioning through REST API POST invocation, you must:
  • Set the payload parameter kubernetes_type to BYO_OKE
  • Configure oke_cluster_id and oke_endpoint together or oke_kubeconfig_path alone under the kubernetes > byo_oke section.

For more information, see Payload Parameters for Siebel CRM Deployment.

You can provision multiple Siebel CRM environments in the same OKE cluster when the "Use Existing Resource" option is selected.

Note: From CM_23.1.0, users can deploy multiple Siebel CRM environments using the same OKE cluster by provisioning each environment in their own namespace. When the "Use Existing Resource" option is selected, we recommend you to use OKE without any existing flux setup. If there is any existing flux setup, you can:
  • Either uninstall using the command: 
    flux uninstall all --namespace=<namespace>
  • Or upgrade existing flux setup with flag --watch-all-namespaces=false to restrict the scope to watch the namespace where the toolkit is installed.

Notes on OCNE (Oracle Cloud Native Environment)

OCNE is an integrated suite of open-source software tools and platform designed to facilitate the development, deployment, and management of cloud-native applications.

OCNE is build around Kubernetes, the leading orchestration platform and includes additional tools and components to enhance Kubernetes capabilities making it easier for organizations to adopt cloud-native technologies in a secure, scalable, and reliable manner.

To use your own OCNE cluster during Siebel CRM environment provisioning through REST API POST invocation, you must:

  • Set the payload parameter kubernetes_type to BYO_OCNE
  • Configure kubeconfig_path under the kubernetes > byo_ocne section.

For more information, see Payload Parameters for Siebel CRM Deployment.

Notes on Other Kubernetes Cluster

To use any other Kubernetes cluster of your choice during Siebel CRM environment provisioning through REST API POST invocation, you must:
  • Set the payload parameter kubernetes_type to BYO_OTHER
  • Configure kubeconfig_path under the kubernetes > byo_other section.

For more information, see Payload Parameters for Siebel CRM Deployment.

Note: We support deployment of Siebel CRM environment on Kubernetes clusters that adhere to Cloud Native Computing Foundation (CNCF) standards.

Notes on BYO Namespace

Bring your own (BYO) namespace refers to the configuration approach of using your own namespace in Kubernetes for Siebel CRM deployment. In Kubernetes, a namespace provides a mechanism for isolating and organizing cluster resources. Here, namespace is the logical division within the Kubernetes cluster in which you want to install Siebel CRM.

You can use BYO namespace in the following scenarios:

  • You have an existing namespace that is managed externally. In this case, ensure that the name of the existing namespace matches the name field in the Siebel CRM deployment payload.
  • You don’t want the namespace to be cleaned up during reruns.

BYO namespace provides flexibility in managing namespaces while leveraging the power of Kubernetes for Siebel CRM provisioning.

To use an existing namespace, you must set the byo_ns parameter to true under the infrastructure > Kubernetes > byo_oke or byo_ocne or byo_others section. When you set the byo_ns parameter to true:

  • SCM will not create the namespace during Siebel CRM deployment.
  • SCM rerun will perform resource cleanup within the namespace. However, it will not delete the namespace itself.
  • SCM will not delete the namespace when the DELETE operation is triggered through the DELETE API.

For more information, see Payload Parameters for Siebel CRM Deployment.

Notes on BYOD (Bring Your Own Database)

SCM can deploy Siebel CRM with Oracle Database only.

When you select the "Use existing resources" option during SCM stack creation, you can use an existing Oracle database, along with other existing resources such as VCN, OKE, mount target, and so on, for your Siebel CRM deployment on OCI. In this case, you must provide the details of the resources as SCM will not create the resources.

However, if you provision an SCM instance without selecting the "Use existing resources" option, BYOD is still supported. In this scenario, you can use your existing database and SCM will provision the rest of the resources, such as OKE, mount target and so on.

Before deploying Siebel CRM using an existing database, you must ensure that you establish connectivity between the existing Siebel CRM database and the:

  • SCM instance and
  • Pods in the Kubernetes cluster

Connecting to an empty (without any data) existing database is not supported.

For more information on the parameters required for using an existing database, see Payload Parameters for Siebel CRM Deployment.

Connectivity Information

The database connection details are used by Siebel CRM applications to establish a connection with the database. You must provide connectivity information, such as wallet credentials and the connection identifier, to ensure secure and successful database access.

The required details in the "BYOD" are:
  • wallet_path: The absolute path of the Oracle net services configuration files or Oracle client credentials (wallet) is required for connecting to the database. The wallet files have to be copied inside the SCM container. The wallet should contain at least the tnsnames.ora for a valid folder. During environment provisioning the wallet will be validated if it contains the tnsnames.ora. TLS enabled wallets are also supported. The provided wallet path will be copied inside the environment directory for usage.
  • tns_connection_name: The connection identifier provided in the field will be validated whether it is present in the tnsnames.ora file or not. If it is not available, a client side validation (400) will be raised.

The provided connection string will be used by the Siebel applications to connect with the database.

If your existing database is on OCI, whether in the same region as your SCM VCN or a different one, you can use private routing to avoid connections through the internet. You must establish a connection from your existing SCM VCN to the VCN where the database resides. The different scenarios where the database can reside and how to establish connection are:

  • Present in the same region:

    If the database is present in the same VCN as the SCM VCN, you must establish local peering between the two VCNs.

    For more information, refer to Local VCN Peering using Local Peering Gateways.

  • Present in different region:

    If your database is present in different region than your SCM VCN, then you must establish Remote peering connection to establish connectivity between both the VCN.

    For more information, refer to Remote VCN Peering using a Legacy DRG.

In the above cases, you will be required to add a route in the route table to allow traffic to the database or vice versa.

Every Siebel CRM deployment requires connectivity from the following subnets:

  • SCM subnet:

    This will be required to run administrative tasks such as verifying if the database is in right shape, are the provided credentials valid etc. This is done prior to creating a Siebel CRM deployment.

  • OKE Nodes subnet:

    This will be required by all Siebel CRM applications to establish connection to the database starting from user authentication to querying tables. For SCM subnet mentioned above, it can be done prior to the deployment, but in case of OKE nodes subnet, they are not yet created at the stage. So, users can provide the OCID of the Dynamic Routing Gateway (DRG) (using the field drg_ocid) which needs to be attached to the OKE Nodes subnet and the destination CIDR block of the DB's subnet or VCN (using the field destination_db_cidr_block) where the traffic has routed through the DRG.

Provided the above are done, the traffic which is controlled by security list also should allow traffic through these ranges. The traffic going outside of SCM instance subnet and OKE nodes subnet are already taken care by the deployment. It will allow traffic to go out. From the database subnet's security rules, similar rules have to be written to allow traffic to come in. In case, the traffic is only controlled through security List, ATP will still require a Network Security Group (NSG) to allow the traffic through it.

For more information, refer to Private Endpoints Configuration Examples on Autonomous Database.

Connectivity Tests

Beforethe provisioning of the environment, you must ensure that the database is accessible from the:

  • SCM instance:
    • Admin User/Password based access
    • Table Owner User/Password based access
    • Guest User access
  • Kubernetes nodes in which the Siebel CRM application lives.

Issues with theses connectivity requirements will be reported in stage "validate-connectivity" and the provisioning activities in OCI for Siebel CRM deployment will be stopped here. The deployment can be re-run after fixing issues related to connectivity.

Workflow Continuation

In the BYOD flow, database import is skipped, and the "import-db-stage" is marked as "Passed."

Debugging Methods

The individual stage logs will record all connection test information and provide detailed results. Logs for connectivity-related tests can be found in the "validate-connectivity" stage. When the tests are passing they leave trail of the events, such as:

  • """
  • admin user validation in progress
  • admin user validation completed
  • tblo user validation in progress
  • tblo user validation completed
  • """

You can perform validations manually using SQL Plus to check. After the issue is fixed, you can rerun the workflow by submitting the payload as before. Common reasons for which the connections might fail are:

  • Host provided in the tnsnames.ora is not reachable.

    Proper connection has to be established to validate this. Incase of OCI, the VCN in which the database resides should have proper security rules to the SCM instance.

    In case of any other externally hosted Oracle database, the guidelines for those providers needs to be followed and whitelisted to provide access to the SCM instance.

  • Invalid info in wallet.

    The data provided in the wallet has to be valid to establish the connection.

  • Invalid authorization information.

    The data provided in the auth_info section has to be valid in order to establish the connection.

Other scenarios which cause failure of connectivity are caught and the details are provided in the stage logs.

Checklist for Creating a BYOR Deployment

Before deploying a BYOR environment, you need to go through a checklist consisting of various steps to ensure that you have a smooth deployment. If the steps or resources are used directly by your environment, without any validation, the application may fail. Here is a resource-wise list of the different steps which need to be performed/validated.

OKE

When using an existing OKE, verify the following:

  • Check if the API server URL is accessible from the SCM instance. If the kube config path is provided, then make sure that the API server is accessible. It can be validated by running basic kubectl commands. If the URL is not accessible, see Debugging Common URL Connectivity Issues to debug.
  • If the Cluster ID is provided while creating a deployment, ensure if the SCM instance's principal (User or Instance principal) has the required access to download kube config. This can be validated by running the following OCI command: 
    oci ce cluster create-kubeconfig --cluster-id <SOME_CLUSTER_ID> --file $HOME/.kube/config --region us-phoenix-1 --token-version 2.0.0  --kube-endpoint PRIVATE_ENDPOINT
  • If the SCM instance uses Instance Principal, verify if the following policy exists:
    'Allow <subject> to manage cluster-family in compartment id <oke_compartment_ocid>'.
    Here <subject> can be group/dynamic_group etc.

    For more information, refer to Policy Syntax documentation.

    Once you have saved the configuration, you need to set the variables for KUBECONFIG and OCI_CLI_AUTH.

    # set the required env variables
# Possible values are - api_key or instance_principal based on your OCI principal configuration.
export OCI_CLI_AUTH=api_key 
# Path to your OKE kube config
export KUBECONFIG=/path/to/your/oke/config
# fetch the cluster info
kubectl cluster-info --request-timeout 5s
# Get the nodes info
kubectl get nodes
  • If it is not accessible, then the instance might not have access to read/use the resource. Either contact your tenancy administrator for proper permissions or check for your policies.
  • If you are behind a proxy, make sure that either the API server is accessible through the Proxy server or if it can be bypassed. Provide it in no_proxy (Contact your administrator for appropriate choice).
  • Login to any one of the nodes and validate if the Git server is accessible by either making a request or cloning a repository etc.

Mount Target

Mount targets' access endpoints are always private endpoints. So inter-network/VCN validations must be done.

  • These are accessed internally. If you are running behind a proxy, chances are your proxy settings might route it to the proxy server. So if it requires to be bypassed, pass it in the no_proxy settings.
  • NFS uses port 2049 by default. One can configure a different port as well. Ensure that your Security List/NSG's have rules to allow the traffic. If the URL is not accessible, see Debugging Common URL Connectivity Issues to debug.
  • NFS client exports are also controlled in mount target and are configured to read or read/write. Ensure that you have read/write permissions on it.
  • Use NFS mount commands to mount a local directory to verify if the SCM instance can communicate. You can unmount the directory after verifying. If you are unable to mount, it is likely that the mount target URL is not reachable. In this case, see Debugging Common URL Connectivity Issues to debug.
    nfs mount <args>
nfs umount <args>
  • Ensure that your mount targets' endpoints are accessible from your OKE nodes. You can verify it by logging in to the OKE's node and checking if the endpoint is accessible. This is a mandatory requirement as the applications need to access the file systems.

Database

You need to validate database endpoints, SID, Listener, and Credentials before creating an environment.

  • Ensure that the endpoints are accessible from both SCM container and the OKE node.
  • To check if the database endpoints are accessible from SCM, connect to the database endpoint using tools such as telnet from the SCM container. You also need to verify if the listener is valid.
  • To check if the database endpoints are accessible from OKE, connect to any one of the OKE nodes and use commands such as telnet to check if they can be reached from there.
  • If the database endpoints are private endpoints (DB endpoints), then there is a chance that your OKE node might not be able to resolve the Host name URL. In such case, verify it with the IP address of the host. If nodes can be setup with an option to resolve the DB hostnames, then IP address will not be required.
  • Verify all the credentials such as: Siebel Admin, Table Owner, anonymous user credentials etc. You can use sqlplus available in the SCM instance to login and validate the credentials.
  • To connect to a database using sqlplus, set the following variables.
    export ORACLE_HOME=/usr/lib/oracle/19.29/client64
export PATH=$PATH:$ORACLE_HOME/bin 
export TNS_ADMIN=/home/opc/siebel/IIG8L6/wallet
  • After setting the variables, connect to sqlplus CLI.
    sqlplus username/password@connection_identifier
# username - db user whom you would like to authenticate
# password - password of that db user.
# connection string which you would like to establish connection and verify with. Can be found in tnsnames.ora

For more information, see the Notes on BYOD (Bring Your Own Database) topic.

Git Repository

The Git instance, where the Helm charts and SCM must be created, should be accessible from both the SCM instance and the OKE nodes. SCM access is required to ensure any changes in release yamls and terraform configuration is tracked.

To verify Git access from the SCM container, log in to the SCM container and run the following commands. If required, to verify from OKE, list down all the OKE Nodes and ssh into any one of the node and run the following steps to verify it:

# Check if you are able to ping to the gitlab IP/URL and access it.
ping gitlaburl.com

OR
# Hit any of the existing gitlab API with the token to verify 
curl  https://gitlaburl.com/api/v4/users --header 'Authorization: Basic token'
# even a 40x response also makes it clear that the URL is accessible
 
# Try to clone an existing repo to verify if SSH access is available
git clone git@gitlaburl.com/repo-name.git # using SSH
Note: The Git instance or repositories should be accessible from both the SCM instance and the OKE nodes.

Debugging Common URL Connectivity Issues

If any URL is not reachable or not able to communicate, you can debug the issue using the following steps.

You can use utilities such as telnet, traceroute, ping, curl etc. Install these utilities using yum/dnf. If you are behind a proxy server and not able to reach the repo, then you need to configure proxy details in /etc/yum.conf

sudo yum install ping curl traceroute telnet
  1. To verify if an URL is accessible or not, verify the security rules/NSG rules of the corresponding resource and the host from which you are connecting.

    For more information, refer to the Network Security Groups documentation.

  2. There is a possibility that there is a secondary barrier also added from resource side, that is ACL for DB's, NFS client export options for mount targets etc. Check if they are whitelisted.

    For more information, refer to the Configure Access Control Lists for an Existing Autonomous Database Instance documentation.

  3. If you are connecting from your on-prem through a Fast connect coupled with a DRG, make sure you have matching rules for your DRG. This is applicable if two or more VCN's are also connected (even with Local Peering Gateway (LPG)).

    For more information, refer to the FastConnect with Multiple DRGs and VCNs documentation.

  4. Check if you are behind a proxy server and your proxy server allows connection to the URL. You can verify this by disabling proxy or adding in no_proxy to test it.
    # verify the list of values set currently
printenv | grep 'PROXY\|proxy'
# update the required var - HTTP_PROXY, HTTPS_PROXY, NO_PROXY
export HTTP_PROXY=myproxyserver.com
  5. Use telnet to see if you are able to reach a URL on a particular URL. Some tools such as sqlplus get hung when a connection does not happen.
    telnet someurl.com 22
Connected to someurl.com
# Port - 22 on someurl.com is reachable from the current host.
 
telnet notreachableurl.com 1522
...
# 1522 on notreachableurl.com is not reachable
  6. Use traceroute to see where exactly the hopping stopped. that is it might go out of an instance but may not go out to the public internet because an IG/NAT was not connected. In this case, the last hop would have been only the VCN.
    traceroute someurl.com
1  hop1.com (10.0.35.153)  292.885 ms  289.622 ms  376.783 ms
2  hop2.com (10.0.32.130)  250.955 ms  250.505 ms  289.326 ms
3  hop3.com (10.0.29.42)  250.155 ms  250.227 ms  290.869 ms
4  hop4.com (10.76.13.210)  271.508 ms  268.169 ms  309.374 ms
5  hop5.com (10.76.13.209)  276.570 ms  273.716 ms  277.106 ms
6  hop6.com (10.76.27.10)  272.482 ms  272.206 ms  269.685 ms
7  hop7.com (10.76.27.68)  269.659 ms  269.013 ms  268.582 ms
8  hop8.com (10.196.6.42)  272.557 ms  273.320 ms  279.004 ms
9  * * *
10  final.destination.com (100.10.14.9)  272.173 ms !Z  271.058 ms !Z  318.078 ms !Z
 
# if it gets hung at ***, then possibly the packet is not able to proceed further from there to the next hop/router.
  7. Ping the URL to verify if the server is up or not. Internet Control Message Protocol (ICMP) has to be enabled).
    ping google.com
PING google.com (172.217.14.78): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
^C
--- google.com ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
# Not able to connect/ping and there is a 100% loss.
 
ping someworkingurl.com
PING someworkingurl.com (100.10.14.1): 56 data bytes
64 bytes from 100.10.14.1: icmp_seq=0 ttl=46 time=284.899 ms
64 bytes from 100.10.14.9: icmp_seq=1 ttl=46 time=271.194 ms
^C
--- someworkingurl.com ping statistics ---
3 packets transmitted, 2 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 271.194/278.047/284.899/6.852 ms
# packets are transmitted, so it can be reached and also provides additional diagnostics info.
  8. cURL a URL to verify if the URL is accessible. Check the response headers for the response code to see what has gone missing. Based on the response headers, validate what could have gone wrong. Here are some sample responses: 400 - Bad request(client side validation), 401 - Bad authorization, 302 - Redirect found.
    curl -I https://oracle.com:443
HTTP/1.0 200 Connection established
 
HTTP/1.1 301 Moved Permanently
Date: Tue, 04 Apr 2023 15:07:52 GMT
Content-Type: text/html
Content-Length: 175
Connection: keep-alive
Location: https://www.oracle.com/
 
# Connection established to oracle.com which means the URL is accessible.

Using Security Adapters for Siebel CRM

This topic is part of Deploying Siebel CRM on OCI.

This section describes how to configure security adapters (security profile) provided with Siebel Business Applications.

SCM supports the configuration of the following security adapter types: DB and LDAP.

The SCM application sets authentication-related configuration parameters for Siebel Business Applications and Siebel Gateway authentication, but does not make changes to the LDAP directory. Make sure the configuration information you enter is compatible with your directory server.

When you specify LDAP as the security adapter type in the payload during environment provisioning, the setting you specify provides the value for the Enterprise Security Authentication Profile (Security Adapter Mode) parameter.

The Security Adapter Mode and Security Adapter Name (named subsystem) parameters can be set for:

  • Siebel Gateway
  • Siebel Enterprise Server
  • All interactive Application Object Manager components

For more information, see the "Security Adapter Authentication" chapter in the Siebel Security Guide.

Use payload parameter security_adapter_type to specifiy the security adapter type. For more information, see Payload Parameters for Siebel CRM Deployment.

If you set the security_adapter_type to:

  • DB, the details in the database payload section are used for configuring security adapter during environment provisioning.
  • LDAP, you must pass the details in the ldap subsection under the siebel section.
Note:
  • For greenfield environment or any lift bucket lifted from SCM version prior to CM_23.7.0, parameters under siebel>ldap sub-section of Payload Elements of SCM under Payload Parameters for Siebel CRM Deployment will be applicable.
  • For lift bucket lifted using SCM version CM_23.7.0 or above and source environment is of security adapter type LDAP, then during shifting (using REST API for deployment), only below user credential parameters will be mandatory (since these information cannot be ‘lifted’) and rest are optional and it will be taken from lifted data if not passed in payload.
    • application_password
    • siebel_admin_username
    • siebel_admin_password
    • anonymous_username
    • anonymous_user_password

For greenfield environment, the value of siebel_admin_username must be SADMIN and value of anonymous_username must be GUESTCST since database will be having only greenfield data.

Example payload section specific to the case when security_adapter_type is LDAP. For complete sample payload structure, see Payload Parameters for Siebel CRM Deployment.

{
      "name": "test173", 
      "siebel": {
      ....
      ....
      "security_adapter_type": "ldap", 
      "ldap":
            {
            "ldap_host_name": <ldap_FQDN>, 
            "ldap_port": "389",
            "application_user_dn": "cn=Directory Manager",
            "application_password": "ocid1.vaultsecret.oc1.uk-london-1.iaheyoqdfpc33khmp42wec", 
            "base_dn": "ou=people,o=siebel.com",
            "shared_db_credentials_dn": "uid=sadmin,ou=people,o=siebel.com", 
            "shared_db_username": "sadmn",
            "shared_db_password": "ocid1.vaultsecret.oc1.uk-london-1.tkyyppq733brnkhmp42wec", 
            "password_attribute_type": "userPassword",
            "siebel_admin_username": "sadmin",
            "username_attribute_type": "uid", 
            "credentials_attribute_type": "mail", 
            "siebel_admin_password": "ocid1.vaultsecret.oc1.uk-london-1.amaaaaaa4n2rr5ia2wcc", 
            "anonymous_username": "GUESTCST",
            "anonymous_user_password": "ocid1.vaultsecret.oc1.uk-london-1.amaaaaaa4n2rnkhmp42was",
            "use_adapter_username": "true",
            "siebel_username_attribute_type" : "uid",
            "propagate_change": "true", 
            "hash_db_password": "true",
            "hash_user_password": "true",
            "salt_user_password": "true",
            "salt_attribute_type": "title"
            }
      }
      "infrastructure": {
      ....
      ....
Example payload section specific to the case when security_adapter_type is LDAP and enable_ssl is set to true (that is, for LDAPs). Note the change in ldap_port value. For complete sample payload structure, see Payload Parameters for Siebel CRM Deployment.
{
      "name": "test173", 
      "siebel": {
      ....
      ....
      "security_adapter_type": "ldap", 
      "ldap":
            {
            "ldap_host_name": <ldap_FQDN>, 
            "ldap_port": "636",
            "application_user_dn": "cn=Directory Manager",
            "application_password": "ocid1.vaultsecret.oc1.uk-london-1.iaheyoqdfpc33khmp42wec", 
            "base_dn": "ou=people,o=siebel.com",
            "shared_db_credentials_dn": "uid=sadmin,ou=people,o=siebel.com", 
            "shared_db_username": "sadmn",
            "shared_db_password": "ocid1.vaultsecret.oc1.uk-london-1.tkyyppq733brnkhmp42wec", 
            "password_attribute_type": "userPassword",
            "siebel_admin_username": "sadmin",
            "username_attribute_type": "uid", 
            "credentials_attribute_type": "mail", 
            "siebel_admin_password": "ocid1.vaultsecret.oc1.uk-london-1.amaaaaaa4n2rr5ia2wcc", 
            "anonymous_username": "GUESTCST",
            "anonymous_user_password": "ocid1.vaultsecret.oc1.uk-london-1.amaaaaaa4n2rnkhmp42was",
            "use_adapter_username": "true",
            "siebel_username_attribute_type" : "uid",
            "propagate_change": "true", 
            "hash_db_password": "true",
            "hash_user_password": "true",
            "salt_user_password": "true",
            "salt_attribute_type": "title"
            "enable_ssl": "true",
            "ldap_wallet_path": "/home/opc/siebel/ewallet.p12",
            "ldap_wallet_password": "ocid1.vaultsecret.oc1.uk-london-1.aaa4noqkyyppq7lf4oamvb7f2cxx"
            }
      }
      "infrastructure": {
      ....
      ....

Using Custom Keystore

SCM uses a custom keystore so you can manage and standardize the TLS certificates and private keys used by Siebel components (and any supporting services). When you deploy Siebel CRM with SCM, you must use two separate certificates: one for server authentication and another for client authentication. The keystore and truststore files are JKS files that store the certificates required for the Siebel TLS configuration:

  • keystore.jks: Contains the Siebel server and Siebel Controller certificates.
  • keystore_client.jks: Contains the Siebel client certificate.
  • truststore.jks: Contains the root certificate.

The JKS files are necessary for the SCM container to use secure two-way communication when connecting with other Siebel CRM components. During Siebel CRM environment provisioning, SCM creates a self-signed certificate and propagates it to all application containers (SES, SAI, and CGW) and controller containers (Metacontroller and Siebel Controller).

You can also bring your own custom certificate. This option lets you keep your private keys within your organization's control, which helps you meet your compliance and security requirements.

Note: We strongly recommend using a Certificate Authority (CA)-signed certificate. Using a CA-signed certificate provides greater control, flexibility, and security over certificate lifecycle management, and is considered a best practice in SCM.

To use a custom certificate:

  1. Generate the custom certificate as follows:
    1. SSH into the SCM instance:
      ssh -i <ssh Private Key> opc@<SCM Host IP>
    2. Enter the container:
      sudo podman exec -it cloudmanager bash
    3. Create a directory to store the custom certificate and set the environment variable ENV_DIR to this directory. For example:
      ENV_DIR=/home/opc/customcerts
    4. Set the following environment variables:
      export HOSTNAME=<SCM_hostname>
export NAMESPACE=<namespace> 
export PASSWORD=xxxxx 
export SUBDOMAIN=svc.cluster.local 
export CLIENT_KEYSTORE=${ENV_DIR}/ca/siebelcerts/siebelkeystore_client.jks
export SIEBEL_SERVER_KEYSTORE=${ENV_DIR}/ca/siebelcerts/keystore.jks
export SIEBEL_CLIENT_KEYSTORE=${ENV_DIR}/ca/siebelcerts/keystore_client.jks 
export SIEBEL_TRUSTSTORE=${ENV_DIR}/ca/siebelcerts/truststore.jks 
export JRE_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::") 
export ALIAS=siebel 
export CONTROLLER_ALIAS='siebel-controller'
export CN=${ENV_DIR##*/}-${NAMESPACE}

      The variables in the example have the following values:

      • <SCM_hostname> is the fully qualified domain name (FQDN) of the SCM host.
      • <namespace> is the value of the:
        • namespace field in the <env_id>_environment.yaml file for an existing environment.
        • name field in the Siebel CRM deployment payload for a new environment.
    5. Copy the openssl.cnf.template file as openssl.cnf, the openssl_controller.cnf.template file as openssl_controller.cnf, and the ca directory to ENV_DIR:
      cd ${ENV_DIR}
cp -r /home/opc/siebel-cloud-manager/scripts/cmapp/initca/ca .
cp ca/openssl.cnf.template ca/openssl.cnf
cp ca/openssl_controller.cnf.template ca/openssl_controller.cnf
    6. Update the openssl.cnf and openssl_controller.cnf files:
      sed -i "s|{{NAMESPACE}}|${NAMESPACE}|g" ca/openssl.cnf
sed -i "s|{{SUBDOMAIN}}|${SUBDOMAIN}|g" ca/openssl.cnf
sed -i "/{{EXTERNALDOMAIN}}/d" ca/openssl.cnf
sed -i "/{{IPADDRESS}}/d" ca/openssl.cnf
sed -i "s|{{NAMESPACE}}|${NAMESPACE}|g" ca/openssl_controller.cnf
    7. Create a folder to store the certificate. For example:
      mkdir -p ${ENV_DIR}/ca/siebelcerts
    8. Generate the certificate as follows:
      1. Generate a private key:
        cd ${ENV_DIR}
openssl genrsa -out ca/private/ca.key.pem 2048
      2. Generate a CA file for the private key:
        openssl req -config ca/openssl.cnf -x509 -sha256 -new -nodes -key ca/private/ca.key.pem -days 1827 -out ca/certs/ca.cert.pem -subj "/CN=${CN}/C=US/ST=California/O=Oracle/L=Redwood Shores/OU=Siebel"
      3. Generate the JAVA keystore and keypair for Siebel server certificate:
        ${JRE_HOME}/bin/keytool -genkeypair -alias ${ALIAS} -validity 365 -keystore ${SIEBEL_SERVER_KEYSTORE} -storetype JKS -keyalg RSA -keysize 2048 -storepass ${PASSWORD} -keypass ${PASSWORD} -sigalg SHA256withRSA -dname "cn=${CN},ou=Siebel,o=Oracle,l=Redwood Shores,ST=California,c=US"
      4. Generate the Siebel server certificate:
        ${JRE_HOME}/bin/keytool -certreq -alias ${ALIAS} -keystore ${SIEBEL_SERVER_KEYSTORE} -file ca/csr/${ALIAS}.csr -storepass ${PASSWORD} -keypass ${PASSWORD}	
openssl ca -batch -config ca/openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in ca/csr/${ALIAS}.csr -out ca/certs/${ALIAS}.cert.pem -passin pass:${PASSWORD}
      5. Generate the keypair for Siebel Controller certificate:
        ${JRE_HOME}/bin/keytool -genkeypair -alias ${CONTROLLER_ALIAS} -validity 365 -keystore ${SIEBEL_SERVER_KEYSTORE} -storetype JKS -keyalg RSA -keysize 2048 -storepass ${PASSWORD} -keypass ${PASSWORD} -sigalg SHA256withRSA -dname "cn=${CN},ou=Siebel,o=Oracle,l=Redwood Shores,ST=California,c=US"
      6. Generate the Siebel Controller certificate:
        ${JRE_HOME}/bin/keytool -certreq -alias ${CONTROLLER_ALIAS} -keystore ${SIEBEL_SERVER_KEYSTORE} -file ca/csr/${CONTROLLER_ALIAS}.csr -storepass ${PASSWORD} -keypass ${PASSWORD}
openssl ca -batch -config ca/openssl_controller.cnf -extensions server_cert -days 375 -notext -md sha256 -in ca/csr/${CONTROLLER_ALIAS}.csr -out ca/certs/${CONTROLLER_ALIAS}.cert.pem -passin pass:${PASSWORD}
      7. Generate the JAVA keystore and keypair for the client certificate:
        ${JRE_HOME}/bin/keytool -genkeypair -alias ${ALIAS} -validity 365 -keystore ${SIEBEL_CLIENT_KEYSTORE} -storetype JKS -keyalg RSA -keysize 2048 -storepass ${PASSWORD} -keypass ${PASSWORD} -sigalg SHA256withRSA -dname "cn=${CN},ou=Siebel,o=Oracle,l=Redwood Shores,ST=California,c=US"
      8. Generate the Siebel client certificate:
        ${JRE_HOME}/bin/keytool -certreq -alias ${ALIAS} -keystore ${SIEBEL_CLIENT_KEYSTORE} -file ca/csr/${ALIAS}_client.csr -storepass ${PASSWORD} -keypass ${PASSWORD}
openssl ca -batch -config ca/openssl.cnf -extensions usr_cert -days 375 -notext -md sha256 -in ca/csr/${ALIAS}_client.csr -out ca/certs/${ALIAS}_client.cert.pem -passin pass:${PASSWORD}
      9. Verify the certificate details:
        openssl x509 -noout -text -in ca/certs/${ALIAS}.cert.pem
openssl verify -CAfile ca/certs/ca.cert.pem ca/certs/${ALIAS}.cert.pem
openssl x509 -noout -text -in ca/certs/${ALIAS}_client.cert.pem
openssl verify -CAfile ca/certs/ca.cert.pem ca/certs/${ALIAS}_client.cert.pem
openssl x509 -noout -text -in ca/certs/${CONTROLLER_ALIAS}.cert.pem
openssl verify -CAfile ca/certs/ca.cert.pem ca/certs/${CONTROLLER_ALIAS}.cert.pem
      10. Import the certificate PEM files (ca.cert.pem, siebel.cert.pem, and siebel-controller.cert.pem to keystore.jks):
        ${JRE_HOME}/bin/keytool -import -trustcacerts -keystore ${SIEBEL_SERVER_KEYSTORE} -alias root -file ca/certs/ca.cert.pem -storepass ${PASSWORD} -keypass ${PASSWORD} -noprompt
${JRE_HOME}/bin/keytool -importcert -alias ${ALIAS} -file ca/certs/${ALIAS}.cert.pem -keystore ${SIEBEL_SERVER_KEYSTORE} -storepass ${PASSWORD} -keypass ${PASSWORD} -noprompt
${JRE_HOME}/bin/keytool -importcert -alias ${CONTROLLER_ALIAS} -file ca/certs/${CONTROLLER_ALIAS}.cert.pem -keystore ${SIEBEL_SERVER_KEYSTORE} -storepass ${PASSWORD} -keypass ${PASSWORD} -noprompt
      11. Import the certificate PEM files (ca.cert.pem and siebel_client.cert.pem) to keystore_client.jks:
        ${JRE_HOME}/bin/keytool -import -trustcacerts -keystore ${SIEBEL_CLIENT_KEYSTORE} -alias root -file ca/certs/ca.cert.pem -storepass ${PASSWORD} -keypass ${PASSWORD} -noprompt
${JRE_HOME}/bin/keytool -importcert -alias ${ALIAS} -file ca/certs/${ALIAS}_client.cert.pem -keystore ${SIEBEL_CLIENT_KEYSTORE} -storepass ${PASSWORD} -keypass ${PASSWORD} -noprompt
      12. Import ca.cert.pem and generate truststore.jks:
        ${JRE_HOME}/bin/keytool -import -trustcacerts -keystore ${SIEBEL_TRUSTSTORE} -alias root - file ca/certs/ca.cert.pem -storepass ${PASSWORD} -keypass ${PASSWORD} -noprompt
      13. Copy keystore.jks to siebelkeystore.jks:
        cp ${SIEBEL_SERVER_KEYSTORE} ${KEYSTORE}
cp ${SIEBEL_CLIENT_KEYSTORE} ${CLIENT_KEYSTORE}
cat ca/certs/ca.cert.pem ca/certs/${ALIAS}.cert.pem > ${ENV_DIR}/ca/siebelcerts/ca-chain.cert.pem
cat ca/certs/ca.cert.pem ca/certs/${ALIAS}_client.cert.pem > ${ENV_DIR}/ca/siebelcerts/ca-chain_client.cert.pem
  2. Copy the keystore.jks, keystore_client.jks, and truststore.jks files to the SCM container. You can also copy the files to the SCM container using File Sync Utility, for more information see Uploading Files to the SCM Container Using File Sync Utility.
  3. Configure the keystore section under the siebel section in the Siebel CRM deployment payload to reference the keystore.jks, keystore_client.jks, and truststore.jks files.

    Here's a sample of the keystore section in the initial deployment payload: 

    "keystore":
{
     "siebel_server_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore.jks",
     "siebel_server_keystore_password": "xxxxxx",
     "siebel_client_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore_client.jks",
     "siebel_client_keystore_password": "xxxxxx",
     "siebel_truststore_path": "/home/opc/customcerts/ca/siebelcerts/truststore.jks",
     "siebel_truststore_password": "xxxxx",
     "siebel_server_certificate_alias": "siebel",
     "siebel_client_certificate_alias": "siebel",
     "siebel_controller_certificate_alias": "siebctrlcert"
}
    Note: If the keystore section isn't configured in the Siebel CRM deployment payload, SCM generates a self-signed certificate and uses it.

During environment provisioning, the JKS files are pushed to the Helm charts Git repository in the siebel- config/keystore directory, which is used by Siebel CRM applications. Additionally, Siebel Controller certificates from the JKS files are pushed to the metacontroller/tls directory in Helm charts Git repository and are used by Metacontroller and Siebel Controller.

You need to follow these rules when creating custom keystore and truststore files:

  • Use the .jks file extension for the Siebel server keystore, Siebel client keystore, and truststore files and set the storeType to JKS.
  • Configure the keystore certificate with the DNS as "*.svc.cluster.local" along with other DNS entries.
  • Import the Siebel certificate into keystore.jks using the alias siebel.
  • Import the Siebel client certificate into keystore_client.jks using the alias siebel.
  • Configure keystore.jks for the Siebel Controller certificate with the DNS name as siebel-controller.<namespace>.svc.cluster.local. Here, <namespace> is the environment name.
  • Sign the Siebel Controller certificate with the same root certificate used to sign Siebel server and client certificates.
  • Import the Siebel Controller certificate into keystore.jks using an alias other than siebel.
  • Create the certificates with a password. Set the password value to siebel.
  • Include the CA certificate, any intermediate certificates, and CSR certificate information in keystore.jks.
  • Include the Siebel client CA certificate, any intermediate certificates, and CSR certificate information in keystore_client.jks.
  • Ensure the Siebel server, Siebel client, and Siebel Controller certificates have only the serverAuth Extended_Key_Usage.
  • Include the CA certificate information in the truststore file.

For more information about updating Keystore file as part of incremental changes, see Use Cases for Updating Keystore File as Part of Incremental Changes.

Terminating SSL/TLS at the Load Balancer (FrontEnd SSL) using SCM

Note: This section is valid only for Siebel CRM environments provisioned with SCM version CM_23.8.1 or higher.

When Container Engine for Kubernetes provisions a load balancer for a Kubernetes service of type LoadBalancer, you can specify that you want to terminate SSL at the load balancer. This configuration is known as frontend SSL. To implement frontend SSL, we have to define a listener at a port such as 443, and associate an SSL certificate with the listener.

Load balancers commonly use single domain certificates. However, load balancers with listeners that include request routing configuration might require a subject alternative name (SAN) certificate (also called multi-domain certificate) or a wildcard certificate. The Load Balancing service supports each of these certificate types.

Oracle Cloud Infrastructure (OCI) accepts x.509 type certificates in PEM format only. The following is an example PEM encoded certificate:

-----BEGIN CERTIFICATE-----
<Base64_encoded_certificate>
-----END CERTIFICATE-----

To terminate SSL certificate at the load balancer with custom SSL certificate, you must supply a certificate during environment provisioning using the following payload parameters:

  • load_balancer_ssl_cert_path
  • load_balancer_private_key_path
  • load_balancer_private_key_password

For more information, see Payload Parameters for Siebel CRM Deployment. If the above optional parameters are not provided during environment provisioning, SCM will generate a self-signed certificate and associate the same with the load balancer listener through Traefik Ingress service.

Updating SSL/TLS Certificates for an Existing Load Balancer Post Deployment

Solution 1 - Updating certificates to existing Load Balancer from OCI Console

  1. Go to the OCI console and navigate to Load Balancer service.
  2. Go to the Load Balancer of the current environment.
  3. Click on Certificates on left menu and select Load Balancer Managed certificate in the Certificate resource dropdown.
  4. Click on Add certificate and upload SSL certificate and private key in respective fields.
  5. Go to the listeners from left menu and edit the listener with name 'TCP-443'.
  6. Select Load Balancer Managed certificate in the Certificate resource dropdown.
  7. Select the new load balancer certificate in the 'certificate name' dropdown.
Solution 2 - Updating certificates and creating new Load Balancer using GitOps setup.
  • If private key is encrypted, first decrypt it using the command:
    openssl rsa -in <load_balancer_private_key_path> -out <decrypted_load_balancer_private_key_path>
  • Create a Kubernetes TLS secret for load balancer SSL certificate using the command:
    kubectl create secret tls lb-tls-certificate --key <decrypted_load_balancer_private_key_path> --cert <load_balancer_ssl_cert_path> -n <namespace>
    Note: If lb-tls-certificate is already present, you need to delete it first using command:
    'kubectl delete secret lb-tls-certificate -n <namespace>'
  • Update the SSL certificate in Ingress definition:
    1. SSH into the SCM instance.
    2. Enter the container:
      sudo podman exec -it cloudmanager bash
    3. Go to the Traefik resources directory:
      cd /home/opc/siebel/<env_id>/<Cloud manager repository name>/flux-crm/traefik/traefik-resources/
    4. Edit the tlsStore.yaml file.
    5. Update secretName under defaultCertificate to lb-tls-certificate if not present.
    6. Push your changes to remote git repository:
      git add .
git commit -m "<message>"
git push

Traefik detects the new secret and reloads it automatically.

Auto-enablement of Siebel Migration Application

This topic is part of Deploying Siebel CRM on OCI.

The Siebel Migration application is a Web-based tool for migrating Siebel Repositories and seed data and performing related tasks, which is provided with the Siebel Application Interface (SAI) installation.

An environment deployed through "lift-and-shift" mechanisms using the lift tool and SCM has the Siebel Migration application auto-enabled in the deployed Siebel CRM environment. Once the deployment is done, Siebel Migration Application endpoint will be included in the URL list with a form ending with /siebel/migration. Use the migration_package_mt_export_path parameter described in Payload Parameters for Siebel CRM Deployment.

Note: Follow SCM Incremental changes model for migrating web artifacts like image files, javascript files, and so on.

For more information about the activities that you can perform in the Siebel Management Console (SMC) post-deployment, refer Siebel Bookshelf.

For more information about troubleshooting, see Troubleshooting a Siebel Cloud Manager Instance or Requested Environment.

Executing the Payload to Deploy Siebel CRM

This topic describes how to execute the payload to deploy Siebel CRM. This topic is part of Deploying Siebel CRM on OCI.

To execute the payload to deploy Siebel CRM

  1. Create an application/json body with the payload information. For an example, see Example Payload to Deploy Siebel CRM.

  2. Do a POST API like the following: 
    POST https://<CM_Instance_IP>:16690/scm/api/v1.0/environment
    Note: Specify a payload appropriate for your use case. For an example payload and for usage guidelines, see Example Payload to Deploy Siebel CRM.

  3. Use Basic Auth and provide credentials like the following: 

    User: "admin"
    Password: "<Password available in the file /home/opc/cm_app/{CM_RESOURCE_PREFIX}/config/api_creds.ini>"

    Environment information is displayed. Copy the selfLink value for monitoring purposes. For example: 

    "selfLink": "https://<CM_Instance_IP>:16690/scm/api/v1.0/environment/4ZZYX5"

Example Payload to Deploy Siebel CRM

To deploy Siebel CRM on OCI, you can prepare and execute the payload based on the following guidelines:

  • To deploy Siebel CRM with the default configuration (greenfield deployment use case 1), omit the config_id parameter.

  • To create a Siebel CRM configuration to customize (greenfield deployment use case 2), use the POST API command in Creating the Configuration and Obtaining the Configuration ID. Make sure you include all payload parameters used in the greenfield deployment for use case 1.

  • To deploy Siebel CRM with a customized configuration (greenfield deployment use case 2), use the POST API command in Executing the Payload to Deploy Siebel CRM. In the payload only include the config_id parameter (set to the configuration ID you obtained when you created the configuration) and name parameter. Omit all other parameters.

  • For usage guidance on additional parameters required for the lift and shift use case or for greenfield deployments, see Payload Parameters for Siebel CRM Deployment.

This section contains the following topics:

Example Payload when "Do not use Vault" Checkbox is Selected 

{
      "config_id": "<config_id of custom configuration>",
      "name": "DevExample",
      "siebel": {
            "registry_url": "iad.ocir.io",
            "siebel_architecture": "CRM",
            "registry_user": "deploygroup/user.name@example.com",
            "registry_password": "<xxxxxx>",
            "bucket_url": "https://objectstorage.us-example-1.oraclecloud.com/p/s0EgeDE9-
         NMc2lTazIY3LuXO1IbGx5ASAilKxJexLHNjirdl4AKJh8RBxou1J4S1/n/deploygroup/b/bucket_example/o/",
            "keystore" : {
                  "siebel_server_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore.jks",
                  "siebel_server_keystore_password": "xxxxxx",
                  "siebel_client_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore_client.jks",
                  "siebel_client_keystore_password": "xxxxxx",
                  "siebel_truststore_path": "/home/opc/customcerts/ca/siebelcerts/truststore.jks",
                  "siebel_truststore_password": "xxxxx",
                  "siebel_server_certificate_alias": "siebel",
                  "siebel_client_certificate_alias": "siebel",
                  "siebel_controller_certificate_alias": "siebctrlcert"
            }
      },
      "infrastructure": {
            "git": {
                  "git_type": "gitlab", 
                  "gitlab": {
                        "git_url": "https://<IP address>", 
                        "git_accesstoken": "<yyyyy>", 
                        "git_user": "<username>",
                        "git_selfsigned_cacert": "/home/opc/certs/rootCA.crt" 
                  }
            },
            "siebel_cluster_subnet_ocid": "<cluster_subnet_ocid>",
            "siebel_lb_subnet_ocid": "<lb_subnet_ocid>",
            "siebel_private_subnet_ocid": "<private_subnet_ocid>",
            "siebel_db_subnet_ocid": "<db_subnet_ocid>",
            "vcn_ocid_of_db_subnet": "<VCN_ocid_of_worker_node>",
            "load_balancer_type": "public",
            "kubernetes": {
                  "kubernetes_type": "OKE",
                  "oke": {
                        "oke_node_count": 3,
                        "oke_node_shape": "VM.Standard.E4.Flex",
                        "oke_node_shape_config": {
                              "memory_in_gbs": 60,
                              "ocpus": 4
                        }
                  }
            }
      },
      "database": {
            "db_type": "ATP",
            "atp": {
                  "admin_password": "<Plain-text of your admin password>",
                  "storage_in_tbs": 1,
                  "cpu_cores": 3,
                  "wallet_password": "<Plain-text of your wallet password's secret>"
            },
            "auth_info": {
                  "siebel_admin_username": "<provide your own values>",
                  "siebel_admin_password": "<Your Siebel admin password's secret in plain-text>",
                  "default_user_password": "<Your default user password's secret in plain-text>",
                  "table_owner_password": "<Your table owner password's secret in plain-text>",
                  "table_owner_user": "<provide your own values>",
                  "anonymous_user_password": "<Your anonymous user password's secret in plain-text>"
            }
      },
      "size": {
            "ses_resource_limits": {
                  "cpu": "2",
                  "memory": "4Gi"
            },
      "ses_resource_requests": {
                  "cpu": "1.0",
                  "memory": "4Gi"
            },
      "cgw_resource_limits": {
                  "cpu": "2",
                  "memory": "4Gi"
            },
      "cgw_resource_requests": {
                  "cpu": "1000m",
                  "memory": "4Gi"
            },
      "sai_resource_limits": {
                  "cpu": "1",
                  "memory": "4Gi"
            },
      "sai_resource_requests": {
                  "cpu": "1",
                  "memory": "4Gi"
            }
      }
}

Example Payload when "Use existing resources" Checkbox is Not Selected

{
      "config_id": "<config_id of custom configuration>",
      "name": "DevExample",
      "siebel": {
            "registry_url": "iad.ocir.io",
            "siebel_architecture": "CRM",
            "registry_user": "deploygroup/user.name@example.com",
            "registry_password": "<xxxxxx>",
            "bucket_url": "https://objectstorage.us-example-1.oraclecloud.com/p/s0EgeDE9-NMc2lTazIY3LuXO1IbGx5ASAilKxJexLHNjirdl4AKJh8RBxou1J4S1/n/deploygroup/b/bucket_example/o/",
            "keystore" : {
                  "siebel_server_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore.jks",
                  "siebel_server_keystore_password": "xxxxxx",
                  "siebel_client_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore_client.jks",
                  "siebel_client_keystore_password": "xxxxxx",
                  "siebel_truststore_path": "/home/opc/customcerts/ca/siebelcerts/truststore.jks",
                  "siebel_truststore_password": "xxxxx",
                  "siebel_server_certificate_alias": "siebel",
                  "siebel_client_certificate_alias": "siebel",
                  "siebel_controller_certificate_alias": "siebctrlcert"
            }
      },
      "infrastructure": {
            "git": {
                  "git_type": "gitlab", 
                  "gitlab": {
                        "git_url": "https://<IP address>", 
                        "git_accesstoken": "<yyyyy>", 
                        "git_user": "<user.name>",
                        "git_selfsigned_cacert": "/home/opc/certs/rootCA.crt" 
                  }
            },
            "siebel_lb_subnet_cidr" : "10.0.1.0/24",
            "siebel_private_subnet_cidr" : "10.0.2.0/24",
            "siebel_db_subnet_cidr" : "10.0.3.0/24",
            "siebel_cluster_subnet_cidr" : "10.0.4.0/24",
            "load_balancer_type": "public", 
            "kubernetes": {
                  "kubernetes_type": "OKE",     
                  "oke": {
                        "oke_node_count": 3,
                        "oke_node_shape": "VM.Standard.E3.Flex",
                        "oke_node_shape_config": {
                              "memory_in_gbs": "60",
                              "ocpus": "4"
                        }
                  }
            }
      }, 
      "database": {
            "db_type": "ATP",
            "atp": {
                  "admin_password": "<OCID of your admin password>",
                  "storage_in_tbs": 1,
                  "cpu_cores": 3,
                  "wallet_password": "<OCID of your wallet password's secret>"
            },
      "auth_info": {
            "siebel_admin_username": "<provide your own values>", 
            "siebel_admin_password": "<OCID of your Siebel admin password's secret>",
            "default_user_password": "<OCID of your default user password's secret>", 
            "table_owner_password": "<OCID of your table owner password's secret>", 
            "table_owner_user": "<provide your own values>", 
            "anonymous_user_password": "<OCID of your anonymous user password's secret>"
            }
      },
      "size": { 
            "ses_resource_limits": {
                  "cpu": "2",
                  "memory": "4Gi"
            },
            "ses_resource_requests": {
                  "cpu": "1.0",
                  "memory": "4Gi"
            },
            "cgw_resource_limits": {
                  "cpu": "2",
                  "memory": "4Gi"
            },
            "cgw_resource_requests": {
                  "cpu": "1000m",
                  "memory": "4Gi"
            },
            "sai_resource_limits": {
                  "cpu": "1",
                  "memory": "4Gi"
            },
            "sai_resource_requests": {
                  "cpu": "1",
                  "memory": "4Gi"
            }
      }
}

Example Payload when "Use existing VCN" Checkbox is Selected

{
      "config_id": "<config_id of custom configuration>",
      "name": "DevExample",
      "siebel": {
            "registry_url": "iad.ocir.io", 
            "siebel_architecture": "CRM",
            "registry_user": "deploygroup/user.name@example.com", 
            "registry_password": "<xxxxxx>",
            "bucket_url": "https://objectstorage.us-example-1.oraclecloud.com/p/s0EgeDE9- NMc2lTazIY3LuXO1IbGx5ASAilKxJexLHNjirdl4AKJh8RBxou1J4S1/n/deploygroup/b/bucket_example/o/",
            "keystore" :
                  {
                  "siebel_server_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore.jks",
                  "siebel_server_keystore_password": "xxxxxx",
                  "siebel_client_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore_client.jks",
                  "siebel_client_keystore_password": "xxxxxx",
                  "siebel_truststore_path": "/home/opc/customcerts/ca/siebelcerts/truststore.jks",
                  "siebel_truststore_password": "xxxxx",
                  "siebel_server_certificate_alias": "siebel",
                  "siebel_client_certificate_alias": "siebel",
                  "siebel_controller_certificate_alias": "siebctrlcert"
                  }
            },
      "infrastructure": {
            "git": {
                  "git_type": "gitlab", 
                  "gitlab": {
                        "git_url": "https://<IP address>", 
                        "git_accesstoken": "<yyyyy>", 
                        "git_user": "<username>",
                        "git_selfsigned_cacert": "/home/opc/certs/rootCA.crt" 
                  }
            },
            "siebel_cluster_subnet_ocid": "<cluster_subnet_ocid>",
            "siebel_lb_subnet_ocid": "<lb_subnet_ocid>",
            "siebel_private_subnet_ocid": "<private_subnet_ocid>",
            "siebel_db_subnet_ocid": "<db_subnet_ocid>",
            "vcn_ocid_of_db_subnet": "<VCN_ocid_of_worker_node>",
            "load_balancer_type": "public", 
            "kubernetes": {
                  "kubernetes_type": "OKE", 
                  "oke": {
                        "oke_node_count": 3,
                        "oke_node_shape": "VM.Standard.E3.Flex",
                        "oke_node_shape_config": {
                              "memory_in_gbs": "60",
                              ocpus": "4"
                        }
                  }
            }
      },
      "database": {
            "db_type": "ATP", 
            "atp": {
                  "admin_password": "<OCID of your admin password>", 
                  "storage_in_tbs": 1,
                  "cpu_cores": 3,
                  "wallet_password": "<OCID of your wallet password's secret>"
                  },
      "auth_info": {
            "siebel_admin_username": "<provide your own values>", 
            "siebel_admin_password": "<OCID of your Siebel admin password's secret>", 
            "default_user_password": "<OCID of your default user password's secret>", 
            "table_owner_password": "<OCID of your table owner password's secret>", 
            "table_owner_user": "<provide your own values>",
            "anonymous_user_password": "<OCID of your anonymous user password's secret>"
            }
      },
      "ses_resource_limits": { 
            "cpu": "2",
            "memory": "4Gi"
            },
      "ses_resource_requests": {
            "cpu": "1.0",
            "memory": "4Gi"
            },
      "cgw_resource_limits": { 
            "cpu": "2",
            "memory": "4Gi"
            },
      "cgw_resource_requests": { 
            "cpu": "1000m",
            "memory": "4Gi"
            },
      "sai_resource_limits": { 
            "cpu": "1",
            "memory": "4Gi"
            },
      "sai_resource_requests": { 
            "cpu": "1",
            "memory": "4Gi"
            }
      }
}

Example Payload when "Use existing resources" Checkbox is Selected

The following is an example payload sent to SCM to deploy Siebel CRM using user provided inputs regarding existing infrastructure for Siebel CRM deployment. Specific section, for example for OKE, for mount target etc. are further given as separate examples in the subsequent sections.

{
      "name": "test1",
      "siebel": {
            "siebel_architecture": "CRM",
            "registry_url": "iad.ocir.io",
            "registry_user": "<registry_user>",
            "registry_password": "<registry_password>",
            "database_type": "Vanilla",
            "industry": "Telecommunications",
            "keystore" : 
                  {
                        "siebel_server_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore.jks",
                        "siebel_server_keystore_password": "xxxxxx",
                        "siebel_client_keystore_path": "/home/opc/customcerts/ca/siebelcerts/keystore_client.jks",
                        "siebel_client_keystore_password": "xxxxxx",
                        "siebel_truststore_path": "/home/opc/customcerts/ca/siebelcerts/truststore.jks",
                        "siebel_truststore_password": "xxxxx",
                        "siebel_server_certificate_alias": "siebel",
                        "siebel_client_certificate_alias": "siebel",
                        "siebel_controller_certificate_alias": "siebctrlcert"	
                  }
      },
      "infrastructure": {
            "git": {
                  "git_type": "gitlab", 
                  "gitlab": {
                        "git_url": "https://<IP address>", 
                        "git_accesstoken": "<gitlab token>", 
                        "git_user": "root",
                        "git_selfsigned_cacert": "/home/opc/certs/rootCA.crt" 
                  }
            },
            "load_balancer_type": "public",
            "siebel_lb_subnet_cidr" : "10.0.1.0/24",
            "siebel_private_subnet_cidr" : "10.0.2.0/24",
            "siebel_db_subnet_cidr" : "10.0.3.0/24",
            "siebel_cluster_subnet_cidr" : "10.0.4.0/24",
            "kubernetes": {
                  "kubernetes_type": "BYO_OKE",  
                  "byo_oke": {
                        "oke_cluster_id": "<cluster-ocid>",
                        "oke_endpoint": "PRIVATE",
                        "oke_kubeconfig_path": "<path-to-kubeconfig-file>"
                        "byo_ns": true 
                  }
            },
            "mounttarget_exports": {
                  "siebfs_mt_export_paths": [
                        {"mount_target_private_ip" : "10.0.255.171","export_path": "/siebfs0"}
                  ]
            } 
      },
      "database": {
            "db_type": "BYOD",
            "byod": {
                  "wallet_path": "/home/opc/certs/wallet",
                  "tns_connection_name": "<provide tns connection name value>"
            },
            "auth_info": {
                  "siebel_admin_username": "<provide your own values>", 
                  "siebel_admin_password": "<OCID of your Siebel admin password's secret>", 
                  "default_user_password": "<OCID of your default user password's secret>", 
                  "table_owner_password": "<OCID of your table owner password's secret>", 
                  "table_owner_user": "<provide your own values>", 
                  "anonymous_user_password": "<OCID of your anonymous user password's secret>"
                  }
            },
      "size": {
            "ses_resource_limits": {
                  "cpu": "2",
                  "memory": "4Gi"
            },
            "ses_resource_requests": {
                  "cpu": "1.0",
                  "memory": "4Gi"
            },
            "cgw_resource_limits": {
                  "cpu": "2",
                  "memory": "4Gi"
            },
            "cgw_resource_requests": {
                  "cpu": "1000m",
                  "memory": "4Gi"
            },
            "sai_resource_limits": {
                  "cpu": "1",
                  "memory": "4Gi"
            },
            "sai_resource_requests": {
                  "cpu": "1",
                  "memory": "4Gi"
            }
      }
}
Note: When using an existing namespace (that is when byo_ns is set to true), you must ensure that the existing namespace name matches the name field in the deployment payload.

Example Database Sections for DBCS_VM Database Type for a BYOD Case

The following is an example database section of the payload for the DBCS_VM database type, using a VM standard shape type:
"database": {
            "db_type": "DBCS_VM",
            "dbcs_vm": {
                  "db_version": "21.0.0.0",
                  "database_edition": "ENTERPRISE_EDITION_HIGH_PERFORMANCE",
                  "availability_domain": "1",
                  "db_home_admin_password": "<OCID of your db home admin password's secret>",
                  "shape": "VM.Standard1.1",
                  "data_storage_size_in_gbs": "512",
                  "db_admin_username": "<provide your own values>",
                  "db_admin_password": "OCID of your db admin password’s secret"
            }
            "auth_info": {
                  "siebel_admin_username": "<provide your own values>", 
                  "siebel_admin_password": "<OCID of your Siebel admin password's secret>", 
                  "default_user_password": "<OCID of your default user password's secret>", 
                  "table_owner_password": "<OCID of your table owner password's secret>", 
                  "table_owner_user": "<provide your own values>", 
                  "anonymous_user_password": "<OCID of your anonymous user password's secret>"
            }
      },

The following is an example database section of the payload for the DBCS_VM database type, using a VM flex shape type:

"database": {
            "db_type": "DBCS_VM",
            "dbcs_vm": {
                  "db_version": "21.0.0.0",
                  "database_edition": "ENTERPRISE_EDITION_HIGH_PERFORMANCE",
                  "availability_domain": "1",
                  "db_home_admin_password": "<OCID of your db home admin password's secret>",
                  "shape": "VM.Standard.E4.Flex",
                  "cpu_count": "2",
                  "data_storage_size_in_gbs": "512",
                  "db_admin_username": "<provide your own values>",
                  "db_admin_password": "OCID of your db admin password’s secret"
            }
            "auth_info": {
                  "siebel_admin_username": "<provide your own values>", 
                  "siebel_admin_password": "<OCID of your Siebel admin password's secret>", 
                  "default_user_password": "<OCID of your default user password's secret>", 
                  "table_owner_password": "<OCID of your table owner password's secret>", 
                  "table_owner_user": "<provide your own values>", 
                  "anonymous_user_password": "<OCID of your anonymous user password's secret>"
            }
      },

The following is an example database section of the payload for the DBCS_VM database type, using BYO-FS with payload parameter dbcs_vm > mount_target_ip and export_path included:

"database": {
            "db_type": "DBCS_VM",
            "dbcs_vm": {
                  "db_version": "21.0.0.0",
                  "database_edition": "ENTERPRISE_EDITION_HIGH_PERFORMANCE",
                  "availability_domain": "1",
                  "db_home_admin_password": "<OCID of your db home admin password's secret>",
                  "shape": "VM.Standard.E4.Flex",
                  "cpu_count": "2",
                  "data_storage_size_in_gbs": "512",
                  "db_admin_username": "<provide your own values>",
                  "db_admin_password": "<OCID of your db admin password’s secret>",
                  "mount_target_private_ip": "<IP address of your mount target>",
                  "export_path": "<Export path in the mount target for using in DATA DIR>"
            },
            "auth_info": {
                  "siebel_admin_username": "<provide your own values>",
                  "siebel_admin_password": "<OCID of your Siebel admin password's secret>",
                  "default_user_password": "<OCID of your default user password's secret>",
                  "table_owner_password": "<OCID of your table owner password's secret>",
                  "table_owner_user": "<provide your own values>",
                  "anonymous_user_password": "<OCID of your anonymous user password's secret>"
            }
},

Example Kubernetes Cluster Sections for BYO-Kubernetes

Payloads for all Kubernetes cluster options.

Example payload when user chooses to go with SCM creating OKE during environment provisioning:

{
      "infrastructure": {
            "kubernetes": {
                  "kubernetes_type": "OKE",     
                  "oke": {
                        "oke_node_count": 3,
                        "oke_node_shape": "VM.Standard.E3.Flex",
                        "oke_node_shape_config": {
                              "memory_in_gbs": "60",
                              "ocpus": "4"
                        }
                  }
            }
      }
}

Example payload when user chooses to use their cluster for environment provisioning and Kubernetes type is BYO_OKE:

{
      "infrastructure": {
            "kubernetes": {
            "kubernetes_type": "BYO_OKE",
            "byo_oke": {
                  "oke_cluster_id": "ocid1.****",
                  "oke_endpoint": "PRIVATE",
                  "oke_kubeconfig_path": "/home/opc/siebel/kubeconfig.yaml"
            },
            "ingress_controller": {
                  "ingress_service_type": "LoadBalancer",
                  "ingress_controller_service_annotations": {
                        "oci.oraclecloud.com/load-balancer-type": "lb",
                        "service.beta.kubernetes.io/oci-load-balancer-internal": "false",
                        "service.beta.kubernetes.io/oci-load-balancer-shape": "flexible",
                        "service.beta.kubernetes.io/oci-load-balancer-shape-flex-min": "10",
                        "service.beta.kubernetes.io/oci-load-balancer-shape-flex-max": "100",
                        "service.beta.kubernetes.io/oci-load-balancer-ssl-ports": "443",
                        "service.beta.kubernetes.io/oci-load-balancer-tls-secret": "lb-tls-certificate",
                        "service.beta.kubernetes.io/oci-load-balancer-subnet1": "ocid1.subnet.oc1.iad.aaaaaaaayt53nlge54fhrhvrnvyvvgqvtenngwz4tqljvpn2chn7ws4chm6q"
                  }
            }
      }
}
}

Example payload when user chooses to use their cluster for environment provisioning and kubernetes type is BYO_OCNE:

{
      "infrastructure": {
            "kubernetes": {
                  "kubernetes_type": "BYO_OCNE",
                  "byo_ocne": {
                        "kubeconfig_path": "/home/opc/siebel/kubeconfig.yaml"
                  }
            },
            "ingress_controller": {
                  "ingress_service_type": "LoadBalancer",
                  "ingress_controller_service_annotations": {
                        "oci.oraclecloud.com/load-balancer-type": "lb",
                        "service.beta.kubernetes.io/oci-load-balancer-internal": "false",
                        "service.beta.kubernetes.io/oci-load-balancer-shape": "flexible",
                        "service.beta.kubernetes.io/oci-load-balancer-shape-flex-min": "10",
                        "service.beta.kubernetes.io/oci-load-balancer-shape-flex-max": "100",
                        "service.beta.kubernetes.io/oci-load-balancer-ssl-ports": "443",
                        "service.beta.kubernetes.io/oci-load-balancer-tls-secret": "lb-tls-certificate",
                        "service.beta.kubernetes.io/oci-load-balancer-subnet1": "ocid1.subnet.oc1.iad.aaaaaaaayt53nlge54fhrhvrnvyvvgqvtenngwz4tqljvpn2chn7ws4chm6q"
                  }
            }
      }
}

Example payload when user chooses to use their cluster for environment provisioning and kubernetes type is OCNE, observability is enabled and local-storage is used for Prometheus and oracle-opensearch:

{
      "infrastructure": {
            "kubernetes": {
                  "kubernetes_type": "BYO_OCNE",
                  "byo_ocne": {
                        "kubeconfig_path": "/home/opc/siebel/kubeconfig.yaml"
                  }
            },
            "ingress_controller": {
                  "ingress_service_type": "LoadBalancer",
                  "ingress_controller_service_annotations": {
                        "oci.oraclecloud.com/load-balancer-type": "lb",
                        "service.beta.kubernetes.io/oci-load-balancer-internal": "false",
                        "service.beta.kubernetes.io/oci-load-balancer-shape": "flexible",
                        "service.beta.kubernetes.io/oci-load-balancer-shape-flex-min": "10",
                        "service.beta.kubernetes.io/oci-load-balancer-shape-flex-max": "100",
                        "service.beta.kubernetes.io/oci-load-balancer-ssl-ports": "443",
                        "service.beta.kubernetes.io/oci-load-balancer-tls-secret": "lb-tls-certificate",
                        "service.beta.kubernetes.io/oci-load-balancer-subnet1": "ocid1.subnet.oc1.iad.aaaaaaaayt53nlge54fhrhvrnvyvvgqvtenngwz4tqljvpn2chn7ws4chm6q"
                  }
            }
      }
},
"observability": {
      "siebel_monitoring": true,
      "oci_config": {
            "oci_config_path": "/home/opc/config/config1",
            "oci_private_api_key_path": "/home/opc/config/oci_api_key.pem",
            "oci_config_profile_name": "DEFAULT"
      },
      "prometheus": {
            "storage_class_name": "local-storage",
            "local_storage_info": {
                  "local_storage": "/mnt/test",
                  "kubernetes_node_hostname": "olcne-worknode-1"
            }
      },
      "oracle_opensearch": {
            "storage_class_name": "local-storage",
            "local_storage_info": [
            {
                  "local_storage": "/mnt/test1",
                  "kubernetes_node_hostname": "olcne-worknode-2"
            },
            {
                  "local_storage": "/mnt/test2",
                  "kubernetes_node_hostname": "olcne-worknode-2"
            },
            {
                  "local_storage": "/mnt/test3",
                  "kubernetes_node_hostname": "olcne-worknode-2"
            }
            ]
      },
      "monitoring_mt_export_path": {
            "mount_target_private_ip": "10.0.1.168",
            "export_path": "/olcne-migration"
      }
}
}

Example Git Section for BYO-Git

If you want to BYO Git, you must configure the byo_git section in Siebel CRM deployment payload. For more information on Git repositories, see Git Repositories for Siebel CRM Deployment.

The following is an example of the git section of the Siebel CRM deployment payload when the git_type parameter is set to byo_git:

Example payload when the Git protocol type is set to http:

{
      "infrastructure": {     
            "git": {
                  "git_type": "byo_git",
                  "byo_git": {
                        "git_protocol_type": "http",
                        "git_scm_repo_url":"https://xxxx.xxxxx.com/xxx/test1/repositories/test1-cm",
                        "git_scm_repo_branch": "main2",
                        "git_scm_flux_folder": "Siebel-crm4",
                        "git_helm_repo_url": "https://xxxx.xxxxx.com/xxx/test1/repositories/test1-cmhc",
                        "git_helm_repo_branch": "main1",
                        "git_accesstoken": "***********",       
                        "git_user": "xxxx.xx@xx.com"
                  }
            }
      }
}

Example payload when the Git protocol type is set to ssh:

{
      "infrastructure": {      
            "git": {
                  "git_type": "byo_git",
                  "byo_git": {
                        "git_protocol_type": "ssh",
                        "git_scm_repo_url":"https://xxxx.xxxxx.com/xxx/test1/repositories/test1-cm",
                        "git_scm_repo_branch": "main2",
                        "git_scm_flux_folder": "Siebel-crm4",
                        "git_helm_repo_url": "https://xxxx.xxxxx.com/xxx/test1/repositories/test1-hc",
                        "git_helm_repo_branch": "main1",
                        "git_ssh_private_key": "/home/opc/siebel/oci_api_key.pem",                  
                        "git_user": " xxxx.xx@xx.com"
                  }
            }
      }
}

Example payload when using existing configuration with byo_git:

"name": "demo1",
"config_id": "OOOAA",
"infrastructure": {
      "git": {
            "git_type": "byo_git",
            "byo_git": {
                  "git_protocol_type": "ssh",
                  "git_scm_repo_url": "ssh://xxxx.xxxxx.com/xxx/test1/repositories/test1-cm",
                  "git_scm_repo_branch": "main2",
                  "git_scm_flux_folder": "siebel-crm4",
                  "git_helm_repo_url": "https:// xxxx.xxxxx.com/xxx/test1/repositories/test1-hc ",
                  "git_helm_repo_branch": "main1",
                  "git_ssh_private_key": "/home/opc/siebel/oci_api_key.pem",
                  "git_user": "xxxx.xx@xx.com"
            }
      },
}
Note: You must use the same Git type for environment provisioning and configuration. For example, if you have set the git_type parameter to byo_git in the configuration payload, then you must set the git_type parameter to byo_git in the provisioning payload also. If the git_type specified in the configuration payload is different from the environment provisioning payload, an error is thrown during the provisioning payload validation.

Example for BYO Namespace

If you want to bring your own namespace, you must set the byo_ns parameter to true under the infrastructure > kubernetes > byo_oke or byo_ocne or byo_others section in Siebel CRM deployment payload. For more information on BYO namespace, see Notes on BYO Namespace.

The following examples show snippets of the kubernetes section of the Siebel CRM deployment payload when the byo_ns parameter is set to true:

Example payload for BYO namespace with byo_oke:

"name": "<byo-namespace>" 
      "infrastructure": { 
      "kubernetes": { 
            "kubernetes_type": "BYO_OKE", 
                  "byo_oke": { 
                  "oke_kubeconfig_path": "/home/opc/.kube/config", 
                  "byo_ns": true 
            } 
      } 
}

Example payload for BYO namespace with byo_other:

"name": "<byo-namespace>" 
      "infrastructure": { 
      "kubernetes": { 
            "kubernetes_type": "BYO_OTHER", 
                  "byo_other": { 
                  "kubeconfig_path": "/home/opc/siebel/kubeconfig.yaml", 
                  "byo_ns": true 
            } 
      }
}
Note: When using an existing namespace (that is, when byo_ns is set to true), you must ensure that the existing namespace name matches the name field in the configuration or deployment payload.

Example for Configuring a Standalone Siebel Gateway

By default, when deploying Siebel CRM using SCM, a three-node Siebel Gateway cluster is created. However, if you want to create a single gateway node without any cluster features, you must set the gateway_deployment_type parameter to standalone under the siebel section in Siebel CRM deployment payload.

The following example shows a snippet of the siebel section of the Siebel CRM deployment payload when the gateway_deployment_type parameter is set to standalone:

Example payload for configuring standalone Siebel Gateway:

{
      "name": "gatewayX",
      "siebel": {
            "registry_url": "xxx.ocir.io",
            "registry_user": "siebeldev/xyz.xx@oracle.com",
            "registry_password": "xxxxx",
            "database_type": "Sample",
            "industry": "Financial Services",
            "gateway_deployment_type": "standalone"
      }
}