7 tips for a successful Oracle SOA Suite upgrade
There are enough reasons to have second thoughts about upgrading your Oracle SOA Suite. But if you know what to look out for, it’s easy to rule out any potential complications during your next version upgrade.
Upgrading key infrastructure components such as Oracle SOA Suite can be a stressful process; as a key component in many people’s software infrastructure the costs of a failed SOA Suite upgrade can be high. At the same time, due to its place as infrastructure, there are often management expectations that an upgrade will be simple and risk free.
This article seeks to provide some tips that can help make sure your SOA Suite upgrade goes smoothly, whether it’s a major version upgrade from 11g to 12c, or a minor version upgrade. Our experience of performing SOA Suite upgrades has highlighted a number of areas that are commonly the cause of complications, and so these are the areas where we focus our tips.
1. Consider the SOA Suite upgrade as a whole
Oracle SOA Suite consists of many parts: as well as the core SOA components of BAM, BPMN, Mediator and their associated database schemas, products such as Oracle BAM, Oracle Event Processor, Oracle Web Service Manager all need to be considered as part of the SOA Suite estate when planning an upgrade. An upgrade may need to be applied to multiple products to maintain compatibility, or products may need to have configuration or meta-data changes made to them to correctly function after the upgrade. As well as the SOA Suite components themselves, an upgrade will likely involve deploying to a new version of WebLogic, and possibly a new Java Virtual Machine. When planning your upgrade, it is therefore important to ensure that you know which components you will be upgrading and that they are all working together as a supported set of versions.
As well as the individual components that make up your SOA Suite estate, you should consider the environments that you have. If you plan to upgrade a reference or pre-production environment before upgrading production then you also need to consider what you will do if you find yourself needing that environment to reproduce production issues after it has been upgraded.
2. Understand your interfaces and the impact of an outage
Key to having a successful upgrade is ensuring that data remains consistent and services don’t fail in unsupported ways. To achieve this it is important that you understand all of the systems that your SOA Suite communicates with, and how they will behave when SOA Suite is down for an upgrade. It may be necessary to shut down some of these systems before you start your upgrade, and bring them back up when it is complete. You may find that systems that cope fine with an outage of a few minutes (for example a server restart), but fail in an ungraceful way when the servers are down for many hours for an upgrade. Don’t assume that just because a system is fine when you restart servers that it will be fine when you perform the upgrade.
Where systems send data to SOA Suite, make sure you know what will happen to that data if SOA Suite is down, and if you need to be able to replay that data into SOA suite, you will need a (tested) approach for doing this.
3. Remember to update documentation
After your upgrade is complete, you should make sure that you update relevant documentation to reflect any changes. As well as just updating the version numbers in design documents you should make sure that any support or test guides have updated paths in them. This is very important to avoid someone accidentally starting an old version of SOA Suite when following a set of instructions with outdated paths.
4. Test alarms
An area that has seen frequent changes, and that is the cause of many post-upgrade problems, is alarms. Oracle uses alarms (also known as scheduled tasks or timers) to schedule actions in a flow to occur at a specific time. The impact of upgrades on alarms can be multiple, depending how they are used in the application, but at the very least you should consider whether any alarms are due to fire during the downtime of the upgrade and how to handle them. After the upgrade is complete you should check that alarms created before the upgrade with trigger times post-upgrade still fire correctly, and that new alarms also work.
If you have any problems you can refresh the alarm table or individual alarms from within Oracle Enterprise Manager Fusion Middleware Control.
5. Check your purging
Purging is important because it prevents your SOA Suite database schemas filling up with entries relating to completed process instances. These old and often irrelevant entries take up space in the database, but more importantly they clog up indexes and slow down performance. Oracle provide a set of purge scripts that can be scheduled to run against the database to clean up some of this old data, and many organizations extend these scripts to take a more business oriented definition of old data.
After an upgrade it is important to remember that these scripts will not have been updated by the upgrade process to reflect any changes to the underlying database schema. Where the default SOA Suite purge scripts are being used you should update your database jobs to call these new scripts. Where custom purge scripts are in use you should identify any necessary changes to the scripts based on the Oracle provided scripts, and make changes to your own scripts as appropriate.
6. Test your back-out strategy
Back-out or rollback strategies are only any use if they have been tested. Ensure that you have run through a trial run of any back-out strategy before you attempt the upgrade and that you understand how long it takes. If you have a hard requirement that the system must be available at 7am on a Monday morning, and you know your back-out procedure takes ten hours, then you need to be finished testing by 9pm on Sunday night and ready to make the decision not to back out of the upgrade.
You also need to understand if there is a “point of no return” in your upgrade (either a technical step, or a time beyond which there is no longer time to complete the back-out before the deadline) and ensure that before reaching that point you have all the information and resources you need to make the correct go or no go decision.
7. Plan well
As we can see, there are lots of things to think about when performing an upgrade of your SOA suite infrastructure, and the ones above are just a few of the more common causes of problems. To make sure your upgrade goes well, you should have rehearsed both the sunny and rainy day scenarios, and have a well-established plan for how you will deal with any post-upgrade problems (How will you get the resources and expertise you require. Are the people that performed the upgrade around afterwards to be able to explain exactly what they did? etc.).