Latest IRM - Siebel upgrade to IP17 +

All right, joking aside - let's talk about the eternal. In this post you will not find a spray of joy or a hint of lightness of being. Because it is for those who fought and searched, passing each new round of Siebel upgrade. Since 2013, Oracle has been campaigning for a fundamental modernization of the CRM system. To date, we have already experienced seven (from IP13 to IP19) innovative Innovation Packs. Until 2013, releases were released once every 2-3 years, the last 5-6 years Siebel updates were published much more often, keeping a clear schedule: minor releases (patchset) were released monthly, brand new versions (major) - annually and often this meant for the client the need global recycling or even "redeployment" of its system. To simplify Siebel upgrades, the vendor has developed IRM (Incremental Repository Merge) - a feature that facilitates the installation of new versions with innovation packages. About him and will be discussed.

IRM principle

In order to upgrade the system to the new version with the Innovation Pack, it is necessary to update the system repository. To do this, you need to merge with the repository of the new version.
The repository is system metadata, i.e. schemes of all that is its functionality. During the project, the development consultants of the customer (Siebel consumer) make thousands of changes to the repository. However, in the release delivery from Oracle, these changes are absent, and the vendor, modifying the system, adds new metadata and in general can completely rework this or that object scheme.

Obviously, there is a need for a mechanism that would allow painlessly to combine the changes made by the consumer of the system with new developments from Oracle. For this, IRM was created.
')
Tasks solved during the Siebel upgrade

1. Preparing repositories and environments to merge.
   
2. Direct Merge on Update Environment (DEV) (IRM).
   
3. Conflict analysis and resolution.
   
4. Applying changes to the update environment.
   
5. Regression testing.
   
6. Correction of all defects that appeared during the update.
   
7. Migrating from update to preproduction and further to production.
   

What is the benefit of switching to IP17 +

1. The new engine: OpenUI - the possibility of deeper adjustment of the interface, which increases the usability of the system.
   
2. Functional analysis of user behavior in the system (Usage Pattern Tracking) will create a unique UX.
   
3. Cross-browser support: IE is no longer a limitation - now you can work in Edge, Firefox, Chrome and Safari.
   
4. The WebTools (Composer) tool allows you to make changes to the interface and business logic of the system from a browser without requiring a server reboot, i.e. without downtime. Prototyping is faster.
   
5. CI / CD technology, patch transfer automation, parallel development, self-testing.
   
6. Support for REST integration technology, which is well applicable when integrating with client portals.
   
7. Industry innovations: from building beautiful analytical dashboards on the popular JS library to Big Data technologies and Machine Learning.
   

The key to a successful upgrade

IRM defines a set of discrepancies in objects and properties that are present in the original repository, in the version of the customer and in the new version. The functionality allows, based on the developer’s decision, to choose how to combine objects and, at the last stage, launch an effective process of migrating the updated repository from the update environment to the production environment.

During the merge conflicts arise, that is, the discrepancies between the properties of the current repository object and the new repository object of the new version.

Non-critical conflicts are discrepancies on objects that were not affected by the customer, i.e. discrepancies between the original repository and the new one. 99% of such conflicts are resolved in favor of the new repository.

Critical conflicts are differences in objects between the client repository and the new repository.

If from the very beginning of the project to follow the methodology of Oracle, the subsequent upgrades will require minimal costs. But, unfortunately, very often the best practices from Oracle are sacrificed when fulfilling certain customer requirements. For example, the system tables are sometimes changed directly through the database, which is not recorded in the Siebel repository. Or change user keys (UK), dimensions and type of standard columns of standard tables, which Oracle strongly recommends not doing. This leads to the impossibility of automatically rebuilding the table in the process of migration to the productive and will require many manual manipulations with tables and data. In addition, changing the standard keys and columns may affect the performance of new processes developed for the new version of Siebel.
Therefore, it is important that the system is implemented under the supervision of certified professionals with extensive implementation experience.

However, the most important thing in the upgrade project is proper planning of the process, during which several issues need to be addressed at once.

Solution Infrastructure

• Who will be involved in setting up the infrastructure:
  
  • deploy servers
  • set the OS
  • configure the RBO
• Description of the update environment. Where are we going to do IRM?
• Description of the test environment. How will we test (including external systems and integration)?
• Description of the implementation environment. Will we update the current production or set up a parallel production-environment?

Detailed project plan (taking into account the distribution of responsibility between the customer and the contractor)

• It is necessary to take into account that it will be necessary to “freeze” the work on the introduction of a new functional on productive.
• Including It should be noted that it will be necessary to reinstall all the packages of the functional that went into production after the start of the upgrade project.

Test plan

• You need to create regression testing scripts.
• Identify those responsible and define a team of testers for both CRM and external systems.

Implementation plan

• To make a check-list of works on the implementation of the upgrade in productive.
• Create a rollback plan (yes !;), in case an accident occurs during the upgrade.

Separately, it makes sense to conduct a full audit of the system (or even order it from a vendor) to find out what violations of the methodology and technical implementation errors the developer has made. The audit is conducted by certified Oracle experts, the results are recorded in the form of “proprietary” Oracle Siebel protocols:

1. Configuration report (errors or irregularities in the business logic configuration)
   
2. Integration report (errors or irregularities in integration objects)
   
3. Script report (errors or irregularities in programmable modules)
   
4. Errors in the processes (errors in workflow and automated functions)
   

The fact is that in the modified functional errors are possible. At the regression testing stage of the combined solution, you will need to understand exactly which error was the result of the combination, and which was originally.

Most Significant Issues When Upgrading Siebel

Latest IRM, or How to upgrade to the latest version of Siebel (IP19)

Over the past 2 years, great changes have occurred in the Siebel system, which have also led to a change in the approach to updating the system.

Key changes related to the release of IP17 in 2017 and its subsequent updates

• The system data model has been reworked, the vendor has abandoned the compile SRF files used when starting the server. Appeared Runtime Repository, which allows you to make changes to the system configuration without rebooting.
  
• Siebel Web Server has become an independent component of Siebel, from this point on, third-party components like IIS and Apache are no longer required. Siebel WebServer received the name Application Interface (AI), it works on the basis of the Tomcat-container. All connections to AI are made only via HTTPS, i.e. all traffic is encrypted by default. AI has full REST support for both incoming requests and outgoing ones (REST technology provides greater flexibility in installing updates to the system and in the process of upgrading repositories).
  
• The Gateway component has been upgraded (now called Dynamic Gateway). Particularly worth mentioning is the reworked internal inter-component balancing. Gateway (Gateway Elastic Load Balancer) is now responsible for it, which makes the load balancing system more flexible - previously this function was performed by the application server.
  
• The system officially supports the Oracle 12 database (support for the Oracle 11g database is complete).
  

In 2018, Oracle changed its release policy for Siebel CRM

• All future innovations and fixes will be delivered as updates, that is, patchsets installed from the distribution kit to the current version (starting with IP17). They will contain innovations previously identified by the vendor in the development strategy of the system.
  
• The names of the patchsets will become clearer, because versions are released monthly: for example, the number 18.4 would mean “April 2018”.
  
• The new delivery model will begin with version 18.4. The latest version of the old model was 17.6. To move from 17.6 to 18.4 you just need to install the distribution (as a patch, not as an IRM upgrade). Subsequent monthly updates may contain functionality for which you will need to download a small package of changes through a special utility. And all updates will be cumulative.
  
• Due to the change in the model, customers who have switched to IP17 will no longer face the problem of missing a patch for their version of the system. This significantly simplifies the process of upgrading the system, reduces the cost of support, and accelerates the implementation of innovative functionality.
  
• To migrate, for example, to version 19 from earlier versions of Siebel (up to 17), it will be necessary to implement a standard upgrade to version 17, and then with the use of a new update model.
  

Changes in the approach to the upgrade to IP17 +

When designing the infrastructure and conducting the sizing, you need to consider the new IP17 server infrastructure. Requirements for iron will be increased, because Runtime Repository requires more resources. Failover balancing of the Application Interface and Gateway components recommends 3 components instead of 2. You will need to revise and transfer the server configuration and enterprise server profiles to the new IP17 architecture.

You will also need to transfer all web artifacts, such as HTML templates, JS, CSS, etc., to the new Application Interface web server. By the way, all web artifacts will eventually move to the system repository.

The next steps are to upgrade the operating system and database to the supported versions (you need to check the Siebel software certification tab for Oracle Support) and issue the correct HTTPS certificate.

Finally, you will only have to run IRM for the last time, and further updates of the versions will go simply through the installation of patches.

If, in parallel with the upgrade to IP17 +, you are developing a new functionality on your current version of the system, then it will need to be re-tested and updated the accompanying documentation. And developers and administrators will be trained to work with the Workspace technology, the Migration Tool utility and the new Siebel Infrastructure Management Console.

You can decide on the approach to the upgrade, which depends on your current version, according to this table:


*** For more information on SEA and SIA Siebel CRM releases, please refer to My Oracle Support article 1514115.1 .

Morality

Obviously, such projects require the involvement of experienced consultants (where to go without them), who are able to foresee and circumvent the pitfalls, to competently plan such an upgrade process, in which the customer will not be left with nothing. Those. minimize and even eliminate the risks of prolonged system downtime, data loss, critical errors in business processes after the upgrade. For example, a wrong choice of a key in a table may entail a large-scale processing of processes in the system — and then a simple update runs the risk of becoming a project for several months.

Maxim Chugunkin, Head of Jet Infosystems Systems Architecture Group