1. Deploying Siebel CRM Containers on Kubernetes using Siebel Cloud Manager
  2. High-Level Steps to Deploy Siebel CRM Using SCM

High-Level Steps to Deploy Siebel CRM Using SCM

This topic describes the high-level steps to deploy Siebel CRM using SCM. Before you review the deployment steps, understand how SCM uses the term BYO.

The term BYO means Bring Your Own. In SCM, BYO refers to existing resources that you provide for deployment. For example, BYOD means Bring Your Own Database.

After you set up SCM, you can deploy Siebel CRM applications in different ways based on the infrastructure information that you provide in the Siebel CRM deployment payload. You can deploy Siebel CRM using one of the following options:

  1. Brings your own resources (fully BYOR): Select Use existing resource when you provision SCM, and provide details of all required resources in the deployment payload, including the existing mount target, file system, OKE cluster, and database. SCM uses this payload information to create Siebel CRM deployments.
  2. Let SCM create all resources: Do not select Use existing resource when you provision SCM. SCM creates and configures the infrastructure required for the Siebel CRM deployment, such as the database, OKE cluster, mount target, file system, and other required resources.
  3. Bring your own database (BYOD) only: Do not select Use existing resource when you provision SCM but provide the existing database information in the deployment payload. SCM creates the remaining infrastructure resources, such as the mount target, file system, and OKE cluster. Make sure that SCM and OKE can connect to the database.

The following are the high-level steps to deploy Siebel CRM on OCI (these are described in detail later in this document):

  1. Set up the Git repository:

    • You can bring your own existing Git repositories hosted on any standards-compliant Git distribution, such as OCI DevOps, GitHub, GitLab, Bitbucket, and so on, or
    • If you want SCM to create the repositories during Siebel CRM provisioning:
      • Set up a GitLab instance.
      • Generate a private key and an access token.

  2. Set up SCM:

    Navigate to OCI and in marketplace applications, select SCM and launch a stack in OCI resource manager.

    If you use a local Git instance that is not a hosted service with a CA-signed certificate, copy the private key from the Git instance to a secure location in the SCM container.

    Provide inputs based on your deployment model, such as BYOR, BYOD, or fully SCM-provisioned deployment.

    For BYOR deployments, select Use existing resource and provide existing resource details, such as the VCN, subnet for launching the instance, policies and so on.

    After the stack job completes successfully, copy the URL from the job output and open it in a browser to verify the SCM setup.

  3. Deploy Siebel CRM:

    1. Create a payload according to your chosen infrastructure provisioning option:
      • For a fully SCM-provisioned Siebel CRM environment, provide the required infrastructure details in the payload. For more information, see Deploying Siebel CRM on OCI.
      • For BYOD, provide the details of the existing database and infrastructure resource.
      • For BYOR, provide the details of all existing resources.
      Note: In case of BYOR or BYOD make sure connection exists between:
      • The database and the OKE cluster.
      • The mount target and the OKE cluster.
    2. Use the /environment API with the POST method to create the Siebel CRM deployment.
      • Review the API response for validation errors or successful environment information.
      • Use the environment entity in the response to monitor deployment progress.
    3. Review the API response for validation errors or successful environment information. Use the environment entity in the response to monitor deployment progress.

Provisioning Status, Logs, and Retry Behavior

SCM provisions the Siebel CRM environment in a series of stages until the SMC and component URLs are published. If a stage fails, SCM marks the stage with a failed status.

You can use the log links in each stage to diagnose issues and take corrective action. Because all stages are idempotent, you can rerun the workflow by using the environment PUT method to restart all stages.