The Camunda Core extension provides a synchronization of CELUM users and groups with Camunda and other utilities. Additionally it gives access to the Camunda REST API via CELUM (/main/camunda/*), so that Workflow extensions in CELUM only need to communicate with CELUM directly.
To be configured in {home}/appserver/conf/custom.properties
type: string, required: yes, default: -
The license key for the plugin (product: camundaCore), provided by brix.
type: string, required: yes, default: -
The URL to the camunda REST API. Has to start with http
or https
and end in /
. E.g. http://localhost:8080/engine-rest/
type: string, required: no, default: -
The username for the Camunda REST API (only required if it is protected).
type: string, required: no, default: -
The password for the Camunda REST API (only required if it is protected).
type: string, required: no, default: -
The token for the services which don't require login (e.g. mail service) to protect them.
Only synchronizes the following events immediately, the rest is done by the sanitize job:
This ensures, that the users can immediately work with Camunda as soon as they are created in CELUM.
type: boolean, required: no, default:
true
Enables/disables the user and group synchronization. Server restart required.
type: string, required: no, default:
0 0 1 * * ?
(hourly)
Quartz cron trigger that tells the sanitize job when and how often it should run.
type: comma-separated list of group ids, required: no, default: - (all groups)
The groups (and members of those groups) which should be synchronized. If this property is not set, all groups are synchronized.
type: boolean, required: no, default:
false
Also synchronize all the sub-groups of the specified groups. Users are always resolved recursively because Camunda doesn't support hierarchical groups (only users can be members of groups and not other groups).
type: string, required: no, default:
CelumUser
The prefix to use for the CELUM users in Camunda. E.g. the user with ID 123 and the default prefix would become CelumUser123 in Camunda.
type: string, requierd: no, default:
CelumGroup
The prefix to use for the CELUM groups in Camunda. E.g. the group with ID 456 and the default prefix would become CelumGroup456 in Camunda.
type: string, required: no, default:
CELUM
The group type of CELUM groups in Camunda. This is just a string and can be anything, but it can be helpful for searching the synchronized groups in Camunda.
The password checker provides an internal service and a controller to verify passwords.
The controller accepts POST requests to /main/camundaCore/password?userId=...&password=...
. userId is optional (defaults to the logged-in user). The following responses are possible:
To be able to use the password checker, the following table has to be created:
create table camunda_password_check_attempts (
id bigint auto_increment primary key,
user_id bigint not null,
timestamp timestamp not null
);
type: integer, required: no, default:
5
After failing the password check this many times in the specified time interval the user will be deactivated.
type: integer, required: no, default:
5
The time interval in minutes.
type: boolean, required: no, default:
true
Delete the failed attempts after successful check?
type: boolean, required: no, default:
true
If set to false, every logged-in user can check the password of any user. Should not be false, otherwise it is possible to lock out other users by intentionally entering a wrong password enough times. This only affects the controller and not the internal password check service.
There is an internal service and a controller to manage the absences. Tasks which are directly assigned to users can be automatically re-assigned to the replacement unless he already has the same task.
The controller provides the following methods to manage absences:
main/camundaCore/absence?userId=...&active=...
both parameters are optional, for userId the default is the logged-in user and the default for active is true (only return absence if it is active). Returns an Absence JSON object.main/camundaCore/absence/list?active=...
only available if loggedInUserOnly is set to false, active is optional and the default is true (only return active absences, not those in the future). Returns a list of Absence JSON objects.main/camundaCore/absence
creates or updates an absence. Has to be send as absence JSON object in the body. userId is optional, the default is the logged-in user.main/camundaCore/absence?userId=...
userId is optional, the default is the logged-in user.Response codes:
Absence JSON object:
{
"id": ...
"userId": 487
"replacementId": 430,
"from": "2020-03-17",
"to": "2020-03-17",
}
To be able to use the absence service, the following table has to be created:
create table camunda_absence (
id bigint auto_increment primary key,
user_id bigint not null,
replacement_id bigint not null,
from_date date not null,
to_date date not null
);
type: boolean, required: no, default:
true
The logged-in user can only request or modify his own absence (recommended).
There is an internal service and a controller to manage observers. Observers can be informed automatically with the mail service.
The controller provides the following methods to manage observers:
main/camundaCore/observer?userId=...
userId is optional, the default is the logged-in user. Returns an Observer JSON object.main/camundaCore/observer/list
only available if loggedInUserOnly is set to false. Returns a list of Observer JSON objects.main/camundaCore/observer
creates or updates an observer, has to be sent as observer JSON object in the body. userId is optional, the default is the logged-in user.main/camundaCore/observer?userId=...
userId is optional, the default is the logged-in user.Response codes:
Observer JSON object:
{
"id": ...
"userId": 487
}
To be able to use the observer service, the following table has to be created:
create table camunda_observer (
id bigint auto_increment primary key,
user_id bigint not null
);
type: boolean, required: no, default:
true
If this property is set to true, then deleted users will be removed automatically from the observer list. Restart required.
type: boolean, required: no, default:
true
The logged-in user can only request or modify his own observer status (recommended).
There is an internal mail service and a controller. Both accept a SendMailRequest object. The mail engine uses velocity templates, which have to be placed in the class path, e.g. CELUM_HOME/appserver/velocity (recommended).
Mail template with all variables:
#* @vtlvariable name="data" type="ch.brix.camundaCore.mail.MailData" *#
#* @vtlvariable name="additionalData" type="java.util.Map<java.lang.String, java.lang.Object>" *#
<div id="body" style="font-family: Arial, Helvetica, sans-serif;">
Always available (all but the first property depend on the recipient), but maybe not set in CELUM:
<ul>
<li>${data.celum}: link to CELUM, guaranteed to end in /</li>
<li>${data.userId}</li>
<li>${data.username}</li>
<li>${data.email}</li>
<li>${data.firstName}</li>
<li>${data.lastName}</li>
</ul>
Available if assetId is set for the request:
<ul>
<li>${data.assetId}: an asset link is created as follows <a href="${data.celum}main/opennodeview.do?assetId=${data.assetId}">${data.assetName}</a></li>
<li>${data.assetName}</li>
</ul>
</div>
The controller accepts POST requests to camundaCore/mail
(note that there is no main) with a SendMailRequest object as the body and the response will be a SendMailResult object (JSON).
The SendMailRequest object has the following properties:
The SendMailResult object properties:
type: string, required: yes, default: -
The email address which should be deplayed in the from field.
type: string, required: no, default: -
If the bcc is set then this email address receives a copy of every mail that was sent with this mail service.
type: boolean, required: no, default:
true
If set to true then deactivated users won't receive any mails and will be ignored.
Camunda Core | CELUM |
---|---|
1.0.0 | 5.13.4 (tested with 6.4) |
Released 2020-03-09
Initial version
© brix IT Solutions