Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

We from “AppWorks Tips” always advice to make a choice upfront to work case-related or task-related. So, will you see a list of cases to work on which you can open and adjust in the best intentions by the knowledge workers, or will you provide them with an inbox where these same users can pick up tasks belonging to a certain case. What you don’t want is mixing the two together, but you’ll quickly experience that AppWorks is hard to configure to only work in a case and completing tasks within it without jumping from one page to another page. Once you figured out a way to purely work from a case layout and managing the tasks within it (and not outside it!), you’ll hit the wall that it’s almost a mission impossible to filter out the cases where you have an assigned task for. This last thing is exactly what we’re going to solve in this post.

Let get right into it…

Let’s do three sections for this post where we start simple and finish like “Mission Impossible”! Boot up the VM where your favorite platform is waiting for you to jump into. Here we start to create a new ‘Case’ entity with a basic property and the default building blocks generated. This is the first impression:

Publish it and see if you can create the first entity instance from the lst_cases list. An easy task, if you tell me…right? Let’s continue…

Case assigned to you

To implement this topic, we require the ‘Assignee’ BB to the entity. We make sure to configure it properly like this:

So, on creation of the case, the current user is automagically the case responsible person (as for this example). Next step to add is an additional list lst_cases_my_claimed (labeled “My cases (claimed)”) with some properties you like to see, but filtered out on the current username:

The $(...) thing is something you just must know, and now you know it too! 💪

Publish it and conclude this works nicely in runtime! Next one…

Case created by you

To implements this topic, we require the ‘Tracking’ BB to the entity. With this BB, you’ll get some extra properties for consumption:

So, on creation of the case, the current user is set as the case creator automatically. Next step is to add a new list lst_cases_my_created (labeled “My cases (created)”) with some properties you like to see, and again filtered out on the current username:

Publish it and conclude again that also this works nicely in runtime! Next…

Any task (in case) assigned to you

To implements this topic, we require the ‘Lifecycle’ BB to the entity. With this BB, you’ll get an extra related ‘LifecycleTask’ entity where you can configure what should happen on task level:

In this related entity we’ll create some rules to fill a “helper” property on the case…We’ll get back to this!

First, we’ll do a Lifecycle BB implementation like this:

Because of this lifecycle, I also add a ‘Tasks’ panel to the lyt_default for managing the received tasks within the entity instance.

We make sure each task assigns to a functional type of role fun_test. This makes sure the task does not directly assign to somebody, but you need to claim it first…This just makes the test (on our new to-be-crafted list) in runtime easier when we’re ready for it.

Don’t forget to apply yourself (and others) to this role via the ‘User manager’ artifact!

Next, we’ll create a new “helper” property case_assignees and make sure you extend the length from default 64 to 1024 as we will concatenate usernames in this field! Also add the ‘Web service’ BB with the ‘Read’ and ‘Update’ operations with this as a result so far:

Notes:

• I also add the case_assigness property on the ‘Create’ form, so you can see and play with the outcome when we evaluate the functionality.
• The ‘Web service’ depends on a service container of type ‘Application Server’, make sure to create one in the ‘System Resource Manager’ artifact. Have a search to accomplish this task for yourself.

…
Time for an ice-tea…🍹
…

Now we only need to make sure each time a ‘lifecycleTask’ entity instance changes, something magic happens with a BPM. That’s a new ‘Rule’ BB on the ‘LifecycleTask’ entity with name e_opc_track_assignees and it looks like this:

The trick here is to make sure you always get a TRUE condition! Simply adding true in the advanced editor is not enough! You really require checking a property. So, we make it an OR-logical-operator checking the same value.
Yes, don’t shoot the messenger; Read more about it here
In the advanced editor it looks like this: item.Task.TaskOwner is null || item.Task.TaskOwner is not null

What about that BPM? It’s a long-lived BPM named bpm_set_assignees_long_lived and saved in the bpms folder of your project with this pseudocode:

1
2
3
4
5
6
7
8

var assignees;
var lifecycleTask = ReadLifecycleTask(rootEntityInstanceId);
var case ReadCase(lifecycleTask.parentEntity.caseItemId);
list activities = "Method Set Notification 1.0".GetActivitiesBySource(case.lifecycle.instanceItemId);
for(var activity : activities) {
    assignees.append(activity.assignee.displayName);
}
UpdateCase(lifecycleTask.parentEntity.caseItemId, assignees);

Some notes:

• I use long-lived because it works on all actions…incl. the revoke and forward.
• The “Stranger Thing” hereby is that I see a direct update on the case_assignees property on the form!? With a long-lived process!? Yes, my friend! This could also be my ‘Tasks’ panel in the layout causing this behavior. Have a comment!
• An ‘Assign’ does not refresh this field directly; That’s not a problem for now as we only require this property for the below list to filter on. If you want that refresh, make a copy of the long-lived process, and make it short-lived with a new ‘Rule’ BB…It’s what it is!
• A final note, in AppWorks 24.3 you can split the events more specifically (like ‘onClaimed’, ‘onRevoked’, etc.)

In the pseudocode, you see a ‘lifecycleTask’ READ operation; For this we need to add the ‘Web service’ BB with corresponding operation on our entity!

Are you still with me? 😁 I do know it’s hard to understand, but hard stuff delivers us this time a valuable feature for any project.

…

BPM implementation

This is the BPM itself:

The only special thing here is the usage of the ‘Runtime reference’ to gain access to service ‘GetActivitiesBySource’! A WHAT? Yes, that’s a reusable component of the platform itself. Create a runtimerefs in your project, right click it for the context menu and choose ‘Add runtime reference’ of type ‘Web Service Interface’ where you need the set Method Set Notification 1.0!

On my first try, I was looking for a method in set Method Set Case Instance Administration 4.2, but the ‘GetModelDetails’, ‘GetCaseInstanceSummary’ and ‘GetActivities’ didn’t give me the required information!

This is the consolidated view of the messagemap:

This post is not to explain all the details about BPM itself; Have a comment if this stuff makes total nonsense!? We’ll plan for a crash-course on BPMs which will enhance your life as a low-code developer.

…

Finally, time for our last ‘List’ BB. Well, the hard part is behind us; get back to the ‘Case’ entity and make a copy of any existing list. Rename it to
lst_cases_my_task_claimed with label “My cases (task claimed)” and implement the filter like this:

For you to copy: $(User.Properties.IdentityDisplayName)

Time for a full publication at project level. After this, move into runtime and create a new ‘Case’ instance. You’ll be the creator and assignee (as already evaluated before), but now assign tasks to yourself or to somebody else in the fun_test role (from the tasks-panel in the open case layout!). You should see an update on the ‘Assignees’ field (hit refresh if not…that’s long-lived BPMs!) and check the new list in the overview screen! I can tell you…It’s working as designed; How nice! 😎 Again, a step closer to “pure” case management as it should be!

Concluding thoughts

I also tried without BPMs, but…

A direct filter like this is not working:

It’s publishable, but you get weird errors in runtime for some reason:

When you change the filter to ‘any of’, and you close and reopen the list, you’ll get the advanced editor! Stuff like this is publishable, but it’s not working in runtime!?

1
2

User.Properties.IdentityDisplayName in (item.LifecycleTask[].Task.TaskOwnerName)
User.Properties.IdentityDisplayName contains (item.LifecycleTask[].Task.TaskOwnerName).toString('|')

…

Before starting this post, I thought about this holy grail ‘Rule’ BB on the ‘LifecycleTask’ entity. It partly works:

Only…during my testing in runtime, I see the case_assignee not getting a proper update with each type of action of the task. After long thinking, I moved into the above BPM implementation which does the job very well!

…

You can download the sources of the AppWorks project of this post here

There you have it; Our “DONE” where you saw unusual ways to filter down lists to your needs. Some are easy, but the last one was a bit harder to accomplish. We learned our lessons and this all grows us in new levels of knowledge where we can use this information to build solid implementations at our customers. Have a great weekend and I see you next week with a new post about “AppWorks Tips”.

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?