AccessAdapter Alternative

[Gromofiz]

Hello

I'm using imixs-jsf-example project for evaluating imixs.
The application is running on a Wildfly 26.1.0.Final instance and what now I'm trying to do is
to implement an alternative of org.imixs.workflow.engine.adapters.AccessAdapter named "org.imixs.application.adapter.AccessAdapterNz"

If i use

@Named("accessAdapter")
@Alternative
public class AccessAdapterNz implements GenericAdapter {
 ...
}

the original bean (org.imixs.workflow.engine.adapters.AccessAdapter) is not overridden and in the workflowKernel.adapterRegister i found:

• org.imixs.workflow.engine.adapters.AccessAdapter
• org.imixs.application.adapter.DemoAdapter

If I add a priority like

@Named("accessAdapter")
@Alternative
@Priority(100)
public class AccessAdapterNz implements GenericAdapter {
 ...
}

in the workflowKernel.adapterRegister i found only AccessAdapterNz and

• org.imixs.workflow.engine.adapters.AccessAdapter
• org.imixs.application.adapter.DemoAdapter

are both missing.
So in the first case my custom implementation is missing and in the second the DemoAdapter is missing causing exception during the execution of an event/signal.

Does someone have any clues? :-)

[rsoika]

I guess you have still an empty bean.xml file, which may cause the problem. Try to add the alternative also into the beans.xml file located in your /WEB-INF/ folder

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
       bean-discovery-mode="all" version="2.0">
	<alternatives>
		<class>com.foo.AccessAdapterNz</class>
	</alternatives>	
</beans>

In general it is not a good idea to replace the AccessAdapter as this class implements the core functionality for securing data. I would recommend you to implement instead an additional Adapter where you add your custom logic.

[Gromofiz]

Hi Ralph,
first .. thanks for tou answer! :-)

The bean.xml contains

    <alternatives>
        <class>org.imixs.application.adapter.AccessAdapterNz</class>
    </alternatives>

so I don't think this is the problem.
The idea behind my question is to set the values of $writeaccess and $readaccess using a db so, depending on the $taskId I can query a db for the values (users and roles).
If I well understand your advice I could disable the AccessAdapter, setting keyupdateacl to false in the model bpmn of the process, and
implements a new adapter ... but the next question is:
can $writeaccess and $readaccess be used by my adapter or new properties must be introduced?
I'm asking this because methods as

workflowService.getWorkListByWriteAccess

use them and, if I introduce new properties, I should "customize" the workflowService functionalities too.

[rsoika]

The Imixs-Workflow engine follows a very fine grained access management regarding read and write access. You can set a Access-Controll-List (ACL) on each process instance processed by the Imixs Workflow engine. The workitem properties $readaccess and $writeaccess can hold a list of userids, groups and roles. The BPMN model defines which users, groups and roles should be able to access a specific process instance in a specific status ($taskid) or after a specific event (you can change the ACL in a BPMN event too). In more complex scenarios each process instance can possible have different read/write access settings.

Think about something like a workflow "application for leave" in an enterprise. The requester and the HR-department should have read access only. The manager should have write access to approve / reject the request. So each process instance have different read and write access settings depending on the requester and his manger.

Its hard to bring this into a database schema. This is why I did not recommand to drop the AccessAdaper without need.

I think what you want to archive is a more dynamic role-resolver. Image you set the $writeaccess with a role 'daily-support-team'. The members can be highly dynamic based on some magic algorithm provided form a database. To archive this, you only need to implement a CDI bean reacting on the org.imixs.workflow.engine.UserGroupEvent

See the section Inject Custom User Groups.

Your implementation may look something like this:

@Stateless
@LocalBean
public class TeamLookupService {
	@Resource
	SessionContext ctx;

	/**
	 * This method updates the UserGroup List and lookup user-groups from a external service.
	 */
	public void onUserGroupEvent(@Observes UserGroupEvent userGroupEvent) {
                // lookup custom groups the user is member of....
		String[] groups = findOrgunits(userGroupEvent.getUserId());
		userGroupEvent.setGroups(Arrays.asList(groups));
	}
	.....
}

Each time a user tries to access a specific process Instance your custom TeamLookupService is called to refresh the user groups list.
So there should be no need to change the AccessAdapter.

[Gromofiz]

Hi Ralph

I tried to follow your advices so I found out that

public void onUserGroupEvent(@Observes UserGroupEvent userGroupEvent)

is called only if I set an ACL to a process/model event (via worflowService.getEvents()), so modifying the process I was able to filter the events a user can see/use depending on his roles.

Following some question and maybe a bug:

1. Can I reach the same result without using event's ACL/UserGroupEvent? For example using DocumentEvent?

2. One question that rised in my mind is: why I can set the the task ACl in two ways? Using the event's ACL or task's ACL.
   The answer i found is: if I use the event's ACL I can change, for example, the task's $writeaccess depending on the choosen path of the process.
   Is it right? Are there other reasons?

3. Doing some testing the method workflowService.getWorkListByWriteAccess() returns zero items even if the $writeaccess where correct.
   I found out that the searchTerm used by the search was:

( type:"workitem" AND ($writeaccess:"admin" OR $writeaccess:"org.imixs.ACCESSLEVEL.READERACCESS" OR $writeaccess:"org.imixs.ACCESSLEVEL.AUTHORACCESS" OR $writeaccess:"org.imixs.ACCESSLEVEL.EDITORACCESS" OR $writeaccess:"role-1100" OR $writeaccess:"role-1200") $writeaccess:"admin" )

Is the last "$writeaccess:"admin" without AND/OR correct? Because without it the right items are returned.
In case have a look at line 305 of WorkflowService

Ciao :-)

[rsoika]

Hi,

The UserGroupEvent is fired by the core document service each time you read or write workflow data (see here). So the UserGroupEvent is used in cases for resolving highly dynamic user roles. This can be a good entry point to solve some complex scenarios. But it is better if you describe a little bit what you try to archive. I expect that the Imixs-Workflow engine already covers your requirements in some way.

To your questions:

1. The ACL is a core concept of Imixs-workflow to protect business data. You should not need to replace this functionality.
2. The ACL on a Task is a kind of default ACL for this workflow status. An event can overwrite this. For example in case of an Escalation event you may want to extend the ACL with additional users like a manager. In most cases setting the ACL on the task is fine
3. The behaviour of the method getWorkListByWriteAccess() is correct. I guess it's just because your workitem has a different acl setting

You can easily check the situation of a workitem if you know the $uniqueid by calling the Rest API:

http://localhost:8080/api/document/{your-unique-id}

And also you can use the Imixs-Admin client to test some of your search queries.

But always keep in mind: If you set the $readaccess than you need to ensure that you have access to the document you request. Only in case you are member of the role org.imixs.ACCESSLEVEL.MANAGERACCESS the ACL will be ignored.

[Gromofiz]

Hi,

I passed some more time "playing" with your framework :-) so ... speaking about 3) I found that the reason was that the default operator for lucene is AND, and not OR: now that I changed the configuration everything works fine.
I'd have two more questions for you:

1. How to make async calls? i.e. how to call a service, with a SignalAdapter I suppose, that you don't know how much time it will take to answer. I had a look to Async Events but I was not able to understand how they work.
2. Is possible to have a paid training? In case I give my email so you can contact me: [email protected]

Enzo

[rsoika]

Hello,

yes, the default operation is AND as this is what users expect using full text search. In a hard coded Lucene Query you better always work with boolean operators to make the query more clear.

Async Calls are quite simple. You add a so called 'Boundery Event' to your Task and connect this event with an existing Imixs-Event accociated with this task:

To the BounderyEvent you than add a timer definition and define the duration interval in milliseconds

This will threat the event as a scheduled event processed by the AsyncEventScheduler.

The AsyncEventScheduler is disabled per default. To activate this feature in your workflow instance you just need to provide the following environment settings:

  ASYNCEVENT_PROCESSOR_ENABLED: "true"
  ASYNCEVENT_PROCESSOR_INITIALDELAY: "10000"

This will enable the processor 10 seconds after deployment.

You will see the corresponding processing messages in your server log file. Also you can check with the Admin Client if open events exits

[Gromofiz]

Hi Ralph,
here I'm again! :-)
I've implemented the following basic workflow for testing asyncevents.

The intermediate catch event is linked to an adapter that simply logs a message every second

public ItemCollection execute(ItemCollection document, ItemCollection event) throws AdapterException {

    int i = 0;	
    // 65 so it takes more than a minute
    while(i < 65){
	    try {
		    synchronized (this) {
			    wait(1000);
		    }
	    } catch (InterruptedException e) {
		    e.printStackTrace();
		    break;
	    }
	    logger.info("i=" + i);
	    i++;
    }
    
    return document;
}	

I have implemented a basic controller to start the process/workflow

    @GET
	@Path("/start")
	public Response startTheProcess(){

		logger.info("startTheProcess");

		ItemCollection workitem = new ItemCollection();
		workitem.setModelVersion("asyncTest-1.0");
		workitem.setTaskID(1000);
		workitem.setEventID(10);
		try {
			ItemCollection itemCollection = workflowService.processWorkItem(workitem);
			System.out.println(itemCollection);
		} catch (ModelException e) {
			e.printStackTrace();
		} catch (PluginException e) {
			e.printStackTrace();
		}
		return Response.status(Response.Status.OK).build();
	}

Everything works but, the problem I have is that the method execute of the adapter is called by the same thread of the request/controller and not in a separate thread by the AsyncService. I think that another way to say the same thing is that no event is created and published .. and I do not understand why?

The AsyncService is running: I can see that is called, after the adapter's execute returns, with a ProcessingEvent whose $taskId's value is 1100, ie "Task 2".

Could you give me a clue?

Following the process definition.

<bpmn2:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" xmlns:ext="http://org.eclipse.bpmn2/ext" xmlns:imixs="http://www.imixs.org/bpmn2" xmlns:xs="http://www.w3.org/2001/XMLSchema" id="Definitions_1" exporter="org.eclipse.bpmn2.modeler.core" exporterVersion="1.5.3.Final-v20210519-2007-B1" targetNamespace="http://www.imixs.org/bpmn2">
  <bpmn2:extensionElements>
    <imixs:item name="txtworkflowmodelversion" type="xs:string">
      <imixs:value><![CDATA[asyncTest-1.0]]></imixs:value>
    </imixs:item>
  </bpmn2:extensionElements>
  <bpmn2:signal id="Signal_2" name="org.imixs.application.adapter.AsyncTestAdapter"/>
  <bpmn2:process id="test_1.0" name="AsyncEventTest" isExecutable="false">
    <bpmn2:startEvent id="StartEvent_1" name="Start Event 1">
      <bpmn2:outgoing>SequenceFlow_1</bpmn2:outgoing>
    </bpmn2:startEvent>
    <bpmn2:task id="Task_1" imixs:processid="1000" name="Task 1">
      <bpmn2:incoming>SequenceFlow_1</bpmn2:incoming>
      <bpmn2:outgoing>SequenceFlow_2</bpmn2:outgoing>
    </bpmn2:task>
    <bpmn2:sequenceFlow id="SequenceFlow_1" sourceRef="StartEvent_1" targetRef="Task_1"/>
    <bpmn2:intermediateCatchEvent id="IntermediateCatchEvent_1" imixs:activityid="10" name="Intermediate Catch Event 1">
      <bpmn2:incoming>SequenceFlow_2</bpmn2:incoming>
      <bpmn2:incoming>SequenceFlow_5</bpmn2:incoming>
      <bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing>
      <bpmn2:dataOutput id="DataOutput_3" name="Signal_2_Output"/>
      <bpmn2:dataOutputAssociation id="DataOutputAssociation_2">
        <bpmn2:sourceRef>DataOutput_3</bpmn2:sourceRef>
      </bpmn2:dataOutputAssociation>
      <bpmn2:outputSet id="OutputSet_2" name="Output Set 2">
        <bpmn2:dataOutputRefs>DataOutput_3</bpmn2:dataOutputRefs>
      </bpmn2:outputSet>
      <bpmn2:signalEventDefinition id="SignalEventDefinition_2" signalRef="Signal_2"/>
    </bpmn2:intermediateCatchEvent>
    <bpmn2:sequenceFlow id="SequenceFlow_2" sourceRef="Task_1" targetRef="IntermediateCatchEvent_1"/>
    <bpmn2:task id="Task_2" imixs:processid="1100" name="Task 2">
      <bpmn2:incoming>SequenceFlow_3</bpmn2:incoming>
      <bpmn2:outgoing>SequenceFlow_4</bpmn2:outgoing>
    </bpmn2:task>
    <bpmn2:sequenceFlow id="SequenceFlow_3" sourceRef="IntermediateCatchEvent_1" targetRef="Task_2"/>
    <bpmn2:endEvent id="EndEvent_1" name="End Event 1">
      <bpmn2:incoming>SequenceFlow_4</bpmn2:incoming>
    </bpmn2:endEvent>
    <bpmn2:sequenceFlow id="SequenceFlow_4" sourceRef="Task_2" targetRef="EndEvent_1"/>
    <bpmn2:boundaryEvent id="BoundaryEvent_1" name="" attachedToRef="Task_1">
      <bpmn2:outgoing>SequenceFlow_5</bpmn2:outgoing>
      <bpmn2:timerEventDefinition id="TimerEventDefinition_1">
        <bpmn2:timeDuration xsi:type="bpmn2:tFormalExpression" id="FormalExpression_1">1000</bpmn2:timeDuration>
      </bpmn2:timerEventDefinition>
    </bpmn2:boundaryEvent>
    <bpmn2:sequenceFlow id="SequenceFlow_5" sourceRef="BoundaryEvent_1" targetRef="IntermediateCatchEvent_1"/>
  </bpmn2:process>

[rsoika]

Hi,

in your example code you trigger the event directly. So no asynchronous processing is performed here.
Your model should look like this:

1. You create a new process instance with the init event.
2. The wokflow will than start the workflow in the status Task-13
3. The async-processor will trigger the "my async event" (you should set this event to 'non public' to avoid that a user triggers the event manually)
4. If the async-event was successful the new task is Task-14
5. If your adapter in the async-event failed for some reason, the task will not change and a retry will be performed in the next cycle.
6. You can optional manual cancel the Task-13 with the event 'Cancel Process'

A typical use case for this kind of modelling is calling external microservices. Depending of the result you can decide to stay in the current task or to continue the process.

[Gromofiz]

Crystal clear, now it works!
Thank you Ralph.

[Gromofiz]

Hi Ralph,

just to know if exists a way/functionality to list running vs ended processes.

Let's say I deployed a set of different process-definitions/model-versions: is there a way to search for
only the running ones? The ones whose current-task/last-task is not an "end-task" or I must introduce a
new property (for example "isEnded" or "processEndDate") in the workitems that I can use in the "searchterm"
for documentService.search() ?

[rsoika]

Hi,
there is a standard attribute called 'type'. Usually this is set to 'workitem'. So to query all running process instances in a specific model is:

(type:workitem) AND ($modelversion:my-workflow-2.0*)

In the modeller you can change the type (e.g. to 'workitemarchive') if a process is completed:

Note: a process instance is always bound to a Task in your model. So you usually have a model end task (setting the ACL and type attribute into a final status)

[Gromofiz]

Got it! :-)

[Gromofiz]

Closed!