In my last blog post “How to trigger process(es) from an automation” I showed you how to create the automation that will trigger the SBPA workflow. Now, I will show you how to turn this autmatomation into a generic solution that can be reused in your projects and shared with other citizen developers/builders on your tenant.
Solution
Creating generic reusable automation
Create a new project (or if you followed the last blog post and created a project you can just duplicate it and delete what is not needed). In our project with generic automation we will need only parts of the previous project. We will leave out context data type (that is specific for every single workflow) and create new inputs for our automation.
Data type “WF API trigger” is the same as described in previous blog post.
FIGURE 1: Data Type (click on picture to enlarge it)
Since our goal is to create a generic automation we will declare all elements that are workflow-dependent (context and workflow definition URL ) as inputs.
FIGURE 2: Declaring inputs (click to enlarge)
Instead of declaring our data type with hard coded values we will use environment variables so we can declare values during deployment. Please note that this approach will work in a typical scenario where you have one SBPA tenant for all your projects. If you need to trigger workflows from any tenant, check the subsection “Optional modification” at the end of this blog post.
FIGURE 3: Creation of environment variables (click to enlarge)
Make sure that your data type has no hardcoded values. We are using 4 environment variables and definition ID (workflow URL) from the input variable.
FIGURE 4: Declare data type and set values (click to enlarge)
Custom Script and activity “Call Web Service” are completely the same so you can just leave them as is (check previous blog post for details).
Now we finished our generic project. Save it. We must publish and deploy our project to be able to add it to the library and reuse.
FIGURE 5: Deploying a project (click to enlarge)
Make sure to enter proper values for all 4 runtime variables (environment variables) in deployment step #2.
After successful deployment, close your project and go back to SAP Build Lobby. You will see that your project is deployed and now you will see action “Publish to Library”.
FIGURE 6: Publish to Library (click to enlarge)
Select the version you want to publish and leave blank Line Of Business and Product tags.
Your project is now published and available for reuse in every project by any builder/developer on your tenant.
Using our generic automation
Let’s now create our regular automation project and switch a view to dependencies. You can see that there are just 2 standard dependencies (core and excel).
FIGURE 7: Dependencies view (click to enlarge)
Now we will add a new dependency. Make sure to select “Add a Business Process project dependency”.
FIGURE 8: Adding new Dependency (click to enlarge)
Select generic project (package) that you just published, select version (if there are more versions) and click add.
FIGURE 9: Select your generic/reusable package (click to enlarge)
Now you can switch to Artifact view and see that you still have your test automation but in the right side pane you will also see automation added as dependency. You can use it as any other element and add it to your project.
FIGURE 10: generic automation is available (click to enlarge)
Now you can add context data type for each workflow you will need to call, declare data type and add values and then add your API call automation. Populate inputs with context and definition ID and run it.
FIGURE 11: Final test automation (click to enlarge)
Optional modification (for multi tenant scenarios)
As you saw, we are defining values of environment variables in the deployment process and they are hardcoded after deployment. Since you provided client secret, client ID, token URL and definition ID for your tenant, you can only call workflows deployed on your BTP tenant.
This is how you will probably use it in most of the cases. Also, this approach is much better if there are multiple developers on your tenant (especially if they are citizen developers) and you don’t want to share client secret and client ID (or create separate key for each developer).
To make it totally generic, you can add those values in your automation as inputs instead of using environment variables. One downside of this approach (and this is why I didn’t show this as a main solution) is that you will need to enter those values EVERY time you call your generic automation. If you need to call it several times in your project, this can be annoying.
If you just occasionally need to call workflows on some other tenant, I would suggest creating 2 automations in your generic project and calling them, for example, “Call Workflow API” and “Call Workflow API external”. You can use environment variables for the local version and inputs for the external version. This will make your everyday development easier.
Conclusion
In this blog post you’ve learned how to create generic automation, make it available for everyone on your tenant and reuse in your regular automation projects. Although I was covering the specific automation case, this is a generic process for any reusable automation.
To stay current will all the new and exciting things related to SBPA please regularly check:
Enjoy building with SAP Build. 🙂
