The workflow feature enables you to add more control and implement business logic to the tasks executed within it. For instance, with the workflow feature, you can add another constraint to the ‘User Add’ operation in the WSO2 Identity Server, that requires manager approval when adding a user account. These are workflows where the operations go through a predefined path.
Let’s imagine a scenario where we need to implement advanced user registration, like this:
- User is registered to WSO2 Identity Server;
- User will get some “basic role” with limited permissions;
- If that registration meets specific criteria, you want to consider manual upgrade of his role to something with more permissions in your system.
Please take a look into the official WSO2 Documentation regarding this topic. It’s pretty much clear how it works, but let’s address the most important:
- You can define your own workflow (process definition) using the standards for this purpose (BPEL / BPMN);
- In order to execute the workflow, you’ll need either WSO2 BPS (which is a part of Enterprise Integrator) or the built-in feature of WSO2 IS for this purpose;
- Users can interact with the flow via the built-in applications (Human Task Explorer, BPMN Explorer) or by using the corresponding APIs;
- Out of the box you’ll get simple monitoring and analytics.
If you follow the Documentation, you’ll learn WSO2 Identity Server is shipped with the basic workflow feature. If you want more control, you can add independent WSO2 BPS as a workflow engine. As soon as you choose one of the pre-defined workflows, Identity Server will create the corresponding flow definition in BPS. If you dig more, you’ll find out that definition is BPEL-based, which is somehow deprecated. Personally, I prefer to work with BPMN, so the question is how to use BPMN instead of BPEL.
In Carbon platform, there is an extension point named workflow executor which is used to implement these workflow extensions. But this article will keep that here just as a reference and I would like to show you different approach.
When you define a BPMN workflow and deploy it as a. bar file to WSO2 BPS, one of the options to start a process instance is via BPS REST API. So, once your process definition is available in BPS, you just need to trigger it from Identity Server.
As our requirement is to take into consideration only already registered users, we can make use of UserStore Event Listener in WSO2 IS. This listener will get triggered many times during the user interaction with the system. You can override the doPostSetUserClaimValues() method, check if the user is initially registered and, if so, you can send traditional JSON POST to BPS, together with relevant user data in the payload. From there you can start desired business workflow, send email notifications, execute process script and service tasks, and finally, send the request back to Identity Server if you want to assign this user to a new role (e.g. a PATCH method via SCIM2 Groups API).
Please read the documentation carefully to understand the concepts and you’ll figure out how it can fit your own requirements.
If you need help, do not hesitate to contact us or to leave a comment in the comments section below.
