How much work can a low-coder do in your project? Is a low-code team self-sufficient? Or do they need to ask for help with coding? Where do we draw a line: should “this” be hard coded in a programming language, or defined in a low-code manner (e.g. in the BPMN process or eximee form template)?
Low-code as much as you can
The low-coded parts of your project are easier to maintain and change. Those parts are also easier to understand thanks to self-documenting notation. Unless a project has some particular requirements (e.g. efficiency) it is better to stay on the low-coded side.
Example!
Send an encrypted email to the customer - a reusable sub-process
Scenario: we’re implementing many business processes for a corporation. Most of those processes are required to send an encrypted email to the customer. To send an encrypted email a process needs to:
- define message attributes (e.g. user identifier, message subject, body template, attachments, etc.)
- call a Webservice which prepares email and puts it on a sending queue
- send a decryption password to the user via SMS
- wait for a message to be sent to the user (from sending queue)
A business process needs to wait until it gets the confirmation of sending a message.
First, let’s examine a “hard-coded” approach.
Our dev team created a straightforward BPMN process, that has one external task with no input parameters. The general concept is: as long as Java code does not have confirmation of sending a message it does not complete a task and therefore it’s blocking the execution of a business process.
To be more specific: upon execution, the Java handler checks whether a messageId variable is set in a process instance:
final String messageId = externalTask.getVariable(DELIVERY_MESSAGE_ID);
if (StringUtils.isBlank(messageId)) {
sendEmail(externalTask);
}
verifyEmailDelivery(externalTask, externalTaskService);
If messageId is empty - we’re sending a new message. It’s not empty - we’re requesting a confirmation:
if (verifyEmailDelivery.verify(details)) {
LOGGER.info("Email with messageId {} is properly send", details.getMessageId());
externalTaskService.complete(externalTask);
} else {
verifyTimeout(externalTask, details);
externalTaskService.extendLock(externalTask, verifyTimeout);
}
Only if we get a confirmation a message is sent we’re completing the external task, i.e. we’re letting the process go on.
The whole processing algorithm in this case is hidden from low-code developers in Java code. To change behavior or to monitor specific parts of it we need to dive into Java.
How this process would look like if we took a more low-code-oriented approach?
In this approach, the algorithm is visible in the BPMN diagram. It is easier to understand. We can also modify the algorithm with low-code tools (e.g. if we were to add some steps after raising an incident).
You should consider using a subprocess to keep main process clutter-free.
Each of the external tasks, implemented in Java, is simpler and more focused on its task - it has narrower requirements.