Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
Just recently I’ve had a number of queries from partners regarding how to go about upgrading SAP Business One within a Cloud environment. In this context when I talk about Cloud I am specifically talking about the SAP Business One Cloud multi-tenant landscape, not a single SAP Business One system hosted on a cloud platform; in the latter case normal SAP Business One upgrade procedures would apply.
Before we go into the process of upgrading SAP Business One tenants (think of a tenant as a company database) it is worth providing some background on the SAP Business One Cloud landscape. The SAP Business One Cloud landscape contains a number of different server components to make it work, many of these play a “supporting” role, i.e. they are not running SAP Business One processes themselves rather providing the infrastructure to make the SAP Business One Cloud work. The main processing happens within Service Units, each service unit contains everything that is required and dedicated to a specific version (down to patch level) of SAP Business One:
Database Instance
Presentation Server(s)
SAP Business One Integration Framework (optional)
SAP Business One Mailer (optional)
Extensions (optional)
Each service unit is responsible for providing SAP Business One to multiple customers (the number will vary according to hardware, number of users and a number of other factors).
This configuration requires us to take a different approach to upgrading tenants within the SAP Business One Cloud landscape compared to company databases in an on-premise installation. The key difference in the approach is that we do not perform an upgrade directly on a database server that holds our SAP Business One tenants as we would do in on-premise SAP Business One. This approach would prove problematic in a cloud installation for a number of reasons:
From the moment we began an upgrade within a service unit the entire service unit would be offline (e.g. once we upgrade the SBO-COMMON database we can no longer login to a tenant that has not been upgraded to the higher version). In a service unit that houses, say, 100 tenants this could cause significant downtime for customers.
Upgrading a tenant can be a resource intensive process, in a multi-tenant environment where infrastructure is shared this has the potential to negatively impact customer experience.
If we did upgrade a whole service unit and there were 100 tenants in a service unit what would happen if we got to tenant 100 and it failed to upgrade when all the others were successful?
For these reasons and others the process of upgrading in SAP Business One Cloud involves two (or possibly three but more on that later) service units. The principle is this:
Service Unit 1 has 100 tenants running SAP Business One 9.0 PL10
Service Unit 2 is created for SAP Business One 9.0 PL11
Tenants (either individually or in batch) from Service Unit 1 are taken offline, backed up, restored to Service Unit 2 and upgraded to SAP Business One 9.0 PL11 where they are again available to the end user.
Of course this is a simplistic approach to upgrades as most partners go through a process of testing a new release before simply “pulling the trigger” on a live upgrade. SAP Business One Cloud provides functionality to assist with this as well as the upgrade process itself:
Pre-upgrade testing - All SAP Business One upgrades must pass pre-upgrade testing, this process can be carried out separately within the SAP Business One Cloud Cloud Control Center in preparation for the upgrade process itself.
Duplicate tenant - Similar to the upgrade process (if duplicating to a service unit that is tied to a higher SAP Business One version) with one key exception - the duplicate tenant is for testing, the original tenant in the source service unit remains live for users to carry on with live transactions. The duplicate tenant can then be tested for extension compatibility, key processes, data etc. before the live upgrade occurs.
Staging Service Units - I mentioned earlier that upgrading tenants can be a resource intensive process, by default this processing will occur in the destination service unit. If we are concerned about the effect on any tenants already in that destination service unit we can introduce a staging service unit. This temporary service unit receives the tenant to be upgraded, upgrades it (ensuring the resources required for processing are not provided by live service units) and then sends it to the destination service unit.
Service Unit Duplication - This process enables you to create a new service unit but automates some of the steps such as deploying the required extensions and moving presentation servers.
As you can see there is a lot of scope within these processes to define your own strategy for the lifecycle management of your SAP Business One Cloud customers. You do not have to follow a strategy of upgrading all of the tenants in one service unit in one go and instead could choose to stage the upgrade into smaller batches of tenants. And if you need to upgrade one tenant urgently for reasons related to a patch you can handle them individually rather than being forced into an unscheduled upgrade for your entire service unit.
So with the concept and functionality explained what is it that you should do in order to upgrade from one patch level of SAP Business One to another?
Check note 1756002, to ensure that the version of SAP Business One that you are upgrading to is supported by the version of SAP Business One Cloud you are running.
Before you begin the process of any upgrades within the SAP Business One Cloud landscape SAP recommends that you create snapshots so thatyou can roll back in case of any errors during the upgrade process.
Register the version of SAP Business One you are upgrading to in the SAP Business One Cloud Software Repository.
Upgrade the SAP Business One License Server to the latest version, this can be done within the SAP Business One Cloud Control Center (not every release of SAP Business One will require an upgrade to the license server but you will receive a message if that is the case)
Create a new service unit
Database Instance - Another database instance needs to be configured and the SBO-COMMON database deployed via the SAP Business One Cloud Control Center.
Presentation Servers need to be assigned to the new service unit, the SAP Business One client is automatically deployed to them. ( Note: these can be unregistered and moved from the source service unit as the resource required in it begins to drop, e.g. in the case of staged upgrade process)
Deploy the required extensions in the new service unit (both SAP and third-party extensions in use)
If you are following our recommendation of using Security Groups to manage access by users to presentation servers you will need to separately configure them to allow the correct user access.
If using the SAP Business One Integration Framework and Mailer these will need to be manually deployed into the new service unit (it is also possible to unregister the existing ones in the source service unit, upgrade them manually and register them to the destination service unit however this would rely on the upgrade for all tenants taking place at one time.)
Perform pre-upgrade tests on the tenants in the source service unit
(Optionally) Perform test upgrades for tenants
Upgrade the tenant to the new service unit, during the time of the upgrade the tenant will not be available to end users.
Once you have completed this process for all tenants all your users will now be logging in to the new service unit and you can power down the old one, reduce it’s resources, use it for testing the next release etc.
To help explain some of the concepts above and demonstrate the process I’ve also recorded the following video:
More information on the upgrade process and other administration steps can be found in the SAP Business One Cloud Administrators Guide, which can be found with the SAP Business One Cloud installations files.
About me:
I've been working at SAP with SAP Business One for the last 9 years in a variety of roles. Currently I look after SAP Business One Cloud and spend much of my time working with partners to help them take advantage of the new and exciting opportunities that have emerged since it's release. You can follow me on Twitter @joelaharris if you want to hear more!
