HR processes¶

• a change in identity's attributes (synchronization / manual change), including contracts etc.
• time event, i.e. role expiration

• stateless - processes all input items
• stateful - remembers processed input items and treats these accordingly

• contextless - to execute the task, only the actual value of the item is required, typically something accessible through SQL query
• contextful - depends on the original value of the item, Idm cannot intercept the change with SQL-like query (without comparison to audit)

Contextless and stateless process is i.e. role expiration. This process does not have an internal state, because all processed items are immediately removed. Description:
1. simple db query finds all expired roles: validTill < :today
2. unassign the roles

An example of contextless and stateful process may be email notification about missing manager. The desired functionality is that the admnistrator is notified only once if identity's manager is missing:
1. find all contracts without manager
2. if the contract has not been processed yet (throughout process history), send a notification somewhere
3. save the contract as processed

• impossible to intercept through SQL query
• the information about original organization is lost after tx commit

## Design proposal¶

### Contextless & stateless tasks¶

Realized as scheduler job / event processor. If more flexibility is needed, the processor or job only starts a predefined Activiti workflow, which realizes the process.

### Contextless & stateful tasks¶

Typically simple HR workflows. The set of items to process is otained via SQL query. The item is processed and if it still matches the defined criteria (the SQL query), it is persisted into process history.
The process has its own queue for processed items (the history). The queue should be modifiable, ideally even through GUI, and would allow the admin to remove items from it (maily testing purposes - rerunning the process).
After each run, the queue (history) performs some kind of self cleaning - all the items the are in history but were not found in SQL criteria are removed from queue.

### Contextful tasks¶

Contextful tasks depend on the original value of the item (attribute). We have to define a place in the application where the change will be intercepted and passed to the HR process (fire an event).
The requirement is that adding / removing of tracked attribute must not involve changes in core BE module and must be configurable at runtime. Also it shall not be limited to the identity entity only (IdmIdentity), but generally applicable to the domain model (implementation is not need, but must be supported, at least for contracts, organizations ets.).

I thought about following places where to intercept the attribute change - I'm open to all other ideas :)

• Dto conversion to entity level
  • support would have to be inserted into all Dto services?

• entity setter level
  • using AOP would be nice
  • ORM can become a problem - may invoke setters

The processing itself could either run immediately after the attribute change event, or could be added to queue and processed as scheduled job (personally I think the latter one is better).

The attribute change event has to be transactional. For example if the change is intercepted on the Dto transformation level, the transaction may rollback somewhere on the lower application levels. In that case the change must not be sumbitted to the HR process.
The queues of contextful tasks will hold the items that shall be processed, therefore the exact opposite purpose then contextless queues, holding the already processed items.

Design proposal for specific processes of standard identity's lifecycle¶

New working position (contract)
Implemented as contextless & stateful process, meaning we do not necessarily need to intercept the change, but can use SQL query. Statefulness means the process needs inner history of processed items.
The SQL query is something like: SELECT e FROM IdmIdentityContract e WHERE e is valid # e is valid replace with date interval on valid[from|till] fields
The process adds default roles onto given (new) contract and enables identity, in case it has been disabled.
The process starts its own Activiti workflow realizing the given task.¶

Working position end (end of contract)
Implemented as contextless & stateful process, meaning we do not necessarily need to intercept the change, but can use SQL query. Statefulness means the process needs inner history of processed items.
The SQL query is something like: SELECT e FROM IdmIdentityContract e WHERE e is not valid # 'e is not valid' replace with date interval on valid[from|till] fields
The process removes all roles from given (expired) contract and disables identity, in case this contract has been identity's last valid contract.
The process starts its own Activiti workflow realizing the given task.¶

Exclusion from active employees (contract exlusion)
Implemented as contextless & stateful process, meaning we do not necessarily need to intercept the change, but can use SQL query. Statefulness means the process needs inner history of processed items.
SQL query select all disabled / enabled contracts and processes them accordingly. It may be desirable to remove / add roles from given (exluded) contract. If there are no more valid contracts for identity, the identity is blocked.
The process starts its own Activiti workflow realizing the given task.¶

There are 2 more processes that are already implemented by IdM features.

New identity - create identity and generate login - done by Synchronization feature
Employee position change - change automatic roles - done by Automatic roles feature

I've rebased the source branch onto current develop.

Exclusion fixed and end of exclusion implemented.
I've done some minor refactoring and added a few tests.

Last issue I'm facing right now is getting the stateful task executors out to REST. Initially I did not have them annotated as @Service or @Component, which did not make them bean candidates and therefore SchedulerManager#getSupportedTasks did not return these.
BUT after I placed the annotation in place, all my beans lack concrete type and are just "JDK Proxies", i.e. some like "com.sun.proxy.$Proxy303".
I've tried a few things to run with Spring but cannot seem to get it working - I'd appreciate any kind of advice here.

The JDK proxy was created because AbstractSchedulableStatefulExecutor, which is a base class for all stateful tasks, had its #process method marked as @Transactional, which I've missed.
Many thanks to Peter for pointing this out.
I've commited the changes, so can you please make code review and test the feature now, Peter?

Also after further discussion with Ondra (sorry for false accusations :)) we have come to conclusion that there is no reliable way of recognizing original default contract, which is assigned to all identities during creation. The original process implementation relied on this being the "main" contract.
I'll discuss how to handle this default contract with others and update the implementation of processes accordingly.

Doc still in progress :)

• stateful tasks: https://proj.bcvsolutions.eu/ngidm/doku.php?id=en:navrh:scheduler
• hr processes: https://proj.bcvsolutions.eu/ngidm/doku.php?id=en:roztridit:standardni_procesy

1. Count of processed records of each process does not reflect reality. For example when running end of contract, number of all found contracts is displayed and not the actual number of processed records.
2. When process has no records to process this information is not displayed and only "Processing" is shown in progress bar instead.
3. Running tasks are never shown as finished even though they are already done. Clinking on "Interrupt task" or "End task" then results in message saying that the task was already finished while leaving the state as it is. Also when interrupting task, returned message misses some arguments