Achieving Digital Transformation with Oracle's Siebel CRM

Siebel CRM 19.3 Update

John Bedford
Director, Product Strategy

Details of the latest Siebel CRM Update release under the Continuous Delivery Model, the Siebel CRM 19.3 Update. This Update was GA on 21st March, 2019.

The features included in this release is as follows:

Workspaces - Enable Seed Data Modification in the Runtime Repository (RR)

The ability to enable List of Values (LOVs) and Workspace-enabled seed data in general to be modified in the Runtime Repository environment.

The Migration utility is also enhanced to support conflict detection/resolution between updates in Source and Target environments based on a system preference that identifies Source v/s Target resolution priority.

Workspace Inspect for REST and SOAP requests

Updated Workspaces infrastructure to allow for REST and SOAP invocations by using metadata defined under Workspace integration and developer branches. Workspace branch versioning is available without the need for explicit invalidation of session stores in the Application Interface.

Online Help Update

Search capability has been added to the end user online help. Content related to new 2018 product features has also been added. The online help is available in all supported languages.

For more information on Siebel CRM Updates, please refer to the Siebel CRM Updates portal.

Join the discussion

Comments ( 4 )
  • Ronny Schoonenberg Tuesday, March 26, 2019

    Good to know! Enable LOV modification is perfect. Depreciation of the Design Repository Data Service is not.

  • John Wednesday, March 27, 2019
    Hi Ronny,

    Design Repository Data Service is a service used to migrate a “Design Repository” to another “Design Repository”. We reviewed this process with some of our customers, in all cases the necessity to move changes between Workspaces in such environments is against the best practices of Workspaces. It would require constant full migration across environments, rather than an incremental migration approach. So to avoid developers falling down this wrong path we decided to deprecate the feature.

    A classic example is to imagine having one Dev environment for large project work and another Dev environment for Production hot fixes. It might be the case that configuration needs to migrate from one Dev environment to the other.

    But the correct approach for development and migration is to use Integration Branches for each release and migrate to QA for testing as many times as necessary.

    You only deliver it to MAIN just before running Incremental Migration from MAIN to Prod. In the meantime, for the above example, you could always create a Dev branch against MAIN for emergency hotfixes and you can use Incremental Migration for Production at all times.

    Hopefully this helps to answer your concern, again it all comes down to the correct and appropriate use of Workspaces and Migration.

    HTH, John
  • KAPIL LAUR Tuesday, April 2, 2019
    What is the alternative for DR migration if the service is off loaded. How the parallel releases can happen .. This is going to hamper customers a lot and for the same reason we STOPPED going to 19.3.
    IWS concept is not working out completely because of various product bugs mainly for REBASE, duplicate issues of LOVs per IWS, Non-SRF(RTEs, DVMs) data not segregated per IWS, Schema changes are not specific to IWS.
    Changes for a future release IWS will be immediately available for current release as well, which is not desired.

    We seriously need some way to have another DEV instance ready with current code base.

  • John Thursday, January 16, 2020
    Hi Kapil,

    I think we have actually resolved some of the issues you describe but please feel free to reach out to our support teams for more guidance.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.