I have been part of recent projects that utilise the SAP Cloud Platform Workflow service and one major improvement area I thought of was in the migration and subsequent deployment of the Workflow definitions throughout the SAP Cloud Platform landscape. This of course could differ depending on the subaccount architecture. With this in mind I thought I would post a small blog on how this can be achieved while also offering some ideas about how this can be improved.
This follows on from a number of blog posts that Mike Doyle covered on the Workflow service which I have included links to below.
I will first provide some context around migrating other similar objects in SAP Cloud Platform in general.
Migrating HTML5 Applications
HTML5 applications can be migrated through to other subaccounts by:
- Exporting the HTML5 application from a subaccount and Importing the application into a different subaccount. The app version can then be activated. e.g. when updating an application from a DEV subaccount to a TEST subaccount.
- Using SAP Web IDE in the TO subaccount, retrieving the latest code from the GIT repository and then deploying to SAP Cloud Platform.
- Setting up a New subscription (in the TO subaccount) that calls the application in the FROM subaccount.
From experience, I find the easiest option by far is the first one. A simple export and import of the application is quick and does not require a large amount of security set up to achieve as some of the other options do. Additionally, I believe that developers have access to SAP Web IDE only in the DEV environment just to further control the development activities and codebase (even though I know with GIT this is not a big deal). Following the first option is in line with this approach whereby the 2nd option would require developers to have access to SAP Web IDE in all environments – not ideal. Note: This is my opinion only!
I am interested in pursuing the 3rd option above however have not actively set this up. I am keen over the coming months to come up with various landscape options for SAP Cloud Platform and have submitted a Teched session to cover this – let’s see if it is accepted :-). Stay tuned!!!
Migrating Portal Sites
Portal sites can also be migrated through to other subaccounts. What I have found and experienced in this area is that you do this only once – mainly because the version numbers of all of the applications are not kept so it is hard to manage the versions of applications between the different subaccounts. Definitely areas for improvement here as well however the way I have typically worked around this is by the first option detailed above. Exporting and Importing of the HTML5 applications individually. This ensures continuity of the app versions between environments – assisting with the support and maintenance activities.
Migrating Workflow Definitions
Having said all of the above, the only way I have found to migrate workflow definitions (and to deploy them) is to use SAP Web IDE. This IMO is a limitation. Totally understand given how the technology works why this is the case but this definitely needs improvement from a developer experience point of view. Definitely a candidate for a #FeatureRequestPhil item. 🙂
Additionally, the approach I mentioned above with having developers only in the DEV environment goes out the door with the way the workflow definitions need to be deployed. While it means further planning up front is involved when determining the landscape configuration it is not ideal. I would like a process similar to the export / import option but will cover this further below.
I will now cover the actual process of migrating the workflows.
A number of steps are involved in migrating workflows, this includes:
- Migrating the application the WF is included in
- Setting up of SAP Web IDE
- Importing of the Workflow Application into SAP Web IDE
- Deploy to SAP Cloud Platform Workflow
- Checking the Workflow Definition has been deployed successfully
Each will be covered in detail now.
Migrating the Workflow Application
Similar to HTML5 applications I think it is good practice to have a self-contained application that is migrated through the landscape that includes the workflow – by itself. In the current project I am involved in a number of different applications were using the same workflow so did not make sense that the workflow would be tied to one of them in the code base. You can deploy the workflow applications to SAP Cloud Platform similar to any other application – the process is the same.
The entire process involves:
- Downloading the workflow from a subaccount. This should save a copy of the application ZIP file to your local machine.
- Uploading this into a different subaccount by using the [Import from File] option. Browse for the application ZIP file you just downloaded.Update the name of the Application as well as the version and select [Import].
The app when first imported will not be active – it will be in Stopped Status.
Activate it by selecting the application and navigating to the Versioning menu and clicking on the Activate icon as shown below.
At this stage, all we have done is migrate the actual Workflow application across to the new subaccount – we have not deployed this as yet. Keep the ZIP file of the application handy as you will need this for the next step.
Set up Web IDE
In the new subaccount, navigate to the SAP Web IDE service and make sure you have the necessary preferences activated. There is a specific Workflow extension setting required to be activated in order to deploy the workflow.
NOTE: You will need the SAP Web IDE related security roles to perform this step.
Go to Tools -> Preferences menu option.
Find the Workflow Editor extension and activate it!
Hit [Save] to make sure this is saved.
Import the WorkFlow Application into Web IDE
Once you have set up SAP Web IDE it is time to import the application. Select the Workspace and then choose the Import option to upload the Workflow (WF) application.
Locate the ZIP file and upload. The app will be uploaded so then open the workflows folder as you can see below.
This completes the importing of the WF application.
Deploy the WF Application
The last step is to actually deploy the WF application to SAP Cloud Platform workflow. The key step here is to make sure you are selecting the workflow and not any of the other components (such as forms, scripts etc).
NOTE: You will need the WorkFlowDeveloper security role to be able to perform this step.
Select the highlighted workflow model and use the right mouse content menu.
You will then receive a message in the console stating that the workflow has been successfully deployed.
Checking the Workflow Definition
The new workflow definition will be added to the list of definitions within the to subaccount. To check, you can run the Workflow Definition app that has been provided. You can navigate to this via the Portal service.
When the default FLP runs the Monitor Workflows – Workflow Definitions application will be included.
When you run this application you will see your new workflow definition that you deployed earlier.
You can then select the [Start New Instance] if you want to create new instances to test out the generation based on the workflow definition.
That concludes the steps involved in the migration of workflows from one subaccount to another in SAP Cloud Platform. There is SAP Help available on this topic however it was a bit light on – have included the links. Transporting workflows link is here and deploying link is here.
During the project there were a number of improvements I thought of.
- Easier Deployments Definitely needs a better deployment process – especially when deploying to other subaccounts. As described during this blog post the Export / Import option is great and easy for applications so something similar for workflows would be great. The activation of the workflow would then automatically deploy to SAP Cloud Platform instead of the subaccount as the HTML5 applications do.
- Removal of the Workflow Definition There was no function available to remove the workflow definition. I found that once you deployed a workflow definition there was no way of removing it. Of course you could update the version by changing the workflow and then deploying again but you could not delete one. From a maintenance and support point of view would be good to have this function as you could end up with a large number of workflows that are simply not used.
- Updating of Workflow Instances During the project we had to make a number of changes to the workflow definition and there really was no way to update the existing workflow instances (from an earlier workflow definition) so that they are up to date. There was some material around workflow form updates here but not everyday workflow field updates.
- Automated Destination Configuration for OAuth Security We had to call the workflow API’s within an application so needed to configure the OAuth client for SAP Cloud Platform workflow in addition to adding the oauth_client security to the Workflow admin global roles. This was quite tricky at first so would be good to have this automated as part of the OAuth client creation.
Overall the experience we had using the Workflow service in SAP Cloud Platform was a good one – it was really easy to create new workflow definitions and after a bit of time easy to utilise the API’s once the connectivity and security was covered. The migration of workflows throughout the environment was also quite easy although as I stated above it can be improved.
This concludes the how to guide for migrating workflows.
Thanks for reading and as per usual feel free to leave your comments and any experiences you’ve had working with the workflow service – especially in the migration of them.