In this post, I share some lessons that I’ve learned while working in a number of Siebel Upgrade projects, including the ones when Siebel was upgraded to IP17+ versions, where Oracle delivered major changes in the Siebel Architecture and Development paradigms, such as Application Interface, Application Containers (Tomcat), Zookeeper, Native Gateway Cluster, Web Tools and Workspaces. As life is a continuous learning experience, so is this post, I will revisit it periodically to add new lessons which I believe are worth to be shared.
Platform certification
First things first. Before jumping into the software installation and all other tasks, it’s important to first check whether the new platform is fully certified with the Siebel version that you’re planning to upgrade to. For such, log into My Oracle Support, navigate to Certifications tab and make sure that OS, Database and everything else is certified against the desired Siebel version (e.g. Windows Server 2019 is certified for Siebel IP21).
Project team collaboration is key
Not only on upgrade projects, but a good team collaboration is crucial for the success of every project. In regards to an upgrade project, I can assure you that a good relationship between Siebel Administrator, DBA, developers and QA testers will result in a smooth and successful project. I am fortunate to have had the opportunity to work with great team members :).
Server script considerations when changing platforms
I can bet that your repository has scripts. In most of the cases that I worked on, customers were using eScript. However, in case you have VBScripts in your repository, please make sure you will still be running your Object Managers in Windows servers because VBScript engine requires Windows libraries, which are not available in Linux and will not work. All this may sound obvious, but sometimes you just forget about to check scripting language in place and move on with the platform change.
Native Gateway clustering solution
Besides the OS cluster implementation that we usually had recommended for the Siebel Gateway server, Oracle has now provided us with a native cluster solution. Since the gateway is a crucial part of the new Siebel Architecture, where every new session needs to pass through the Gateway, I highly recommend you to deploy the native gateway cluster on at least 3 nodes. They can be co-located with the application servers, just make sure to deploy them in separated physical host machines in case you’re running VMs.
List of Values and Web Templates are now part of the Repository
If you already started planning your upgrade and did your initial research, chances are that you already know that LOVs and Web Templates are now part of the Siebel Repository. But, what it really means in terms of the upgrade process? For Web Templates, there’s a process that is run automatically during the upgrade process that will read your .swt files and import them to the database. If you have made changes to some vanilla file, those will not be imported. For the LOVs, there’s nothing much special you need to do during the upgrade process. However, it will demand more attention from your team on how LOVs are now managed under Workspaces. Please check Oracle’s documentation on how to properly create/modify yours LOVs to avoid problems when you migrate you repository to other environments.
Your application URL will change, so prepare for it!
On this new version, SWSE was replaced by a Java 64-bit application which runs on a Tomcat server. It allows traffic using TLS connection (HTTPS). It also means that the old Siebel URL style has changed. Instead of http://<hostname>/ecommunications_enu your application will now be accessible by https://<hostname>/siebel/app/ecommunications/enu. Therefore, be prepared to inform your users about the new URL after the rollout. It is also possible to setup a reverse-proxy to keep the old format. However, if you have the chance, I would suggest you to try to move on to the new URL format as soon as you rollout the new version.
Are you using Single Sign-On (SSO)? Prepare for a reverse-proxy implementation
Depending on your Single Sign-On solution, you will not have available a Tomcat plug-in. This was the case in 100% of the projects I’ve participated so far. In cases like this I implemented a web server (IIS or apache) in front of Siebel’s Tomcat withs the SSO plug-in installed. It would then act as a reverse-proxy for Siebel application.
Optimize your database backup/restore with Oracle Flashback
Things can (and most probably will) go wrong during the upgrade. So it’s important to backup your database as you proceed with the upgrade steps. In case you’re using Oracle Database, there’s a feature called Flashback, which allows you to quickly undo database changes up to a restore point. This will save you hours of db restore time as flashback usually takes only a couple of minutes to go back to the pre-upgrade state. Talk about it with your DBA and optimize your backup/restore process.
Golden Gate is gold
On customers that couldn’t afford large downtimes for the Go-Live, Oracle Golden Gate proved to be a helpful (and sometimes magical) resource to minimize the rollout window. Golden Gate connects two different databases and keeps synchronizing data from source to target applying transformations when necessary. For such scenarios, we configured it to replicate all data but Repository tables, which is updated only by the upgrade process. This strategy allowed us to have the to-be production environment ready way before the Go-Live date so, during the rollout we only need to shutdown the old application, wait for the replication to finish, then start the new application using the target database as the primary db. It also allowed us to test the new environment before the Go-Live.
Test, test, test and Stress Test!
It is crucial that you run a thoroughly test after you upgrade your development or test environment as new issues probably will occur in the new version. Not only functional tests are important but Stress Tests too. Sometimes you will only be able to identify performance bottlenecks or memory leaks when you increase the load in your application servers and database. So plan accordingly and run the most comprehensive possible test scenarios that you can!