Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
During our AppWorks journey we saw something interesting that we just want to share with you as you would not expect to find this kind of information in the described location. We’re talking about the lifecycles that can be used as a building block on the entities. These lifecycles can also be ‘Case Models’ what we’ll also briefly explain in the end.
Let get right into it…
We’ll directly start with our favorite workspace with our ‘awdev’ user. Pick an entity (in my case the ‘Category’) and add a lifecycle building block to it.
Yes indeed, I make the assumption that you can create instances with this entity in runtime. So, have those ‘Create’ and ‘Default’ form with that ‘AllCategories’ list in place.
And create something real clean, simple like this
Save it and publish the entity!
For now, it’s enough to know that every time you create a new instance of the entity the lifecycle will start running. Normally we also add tasks to it but is not required for now!
Next step is to jump into the artifact ‘Case Instance Manager’. To see this artifact, you need to have the ‘Administrator’ role. For me it’s the ‘sysadmin’ user.
Question: Why ‘Case Instance’ and why not ‘Lifecycle Instance’?
This had to do with the history of the AppWorks suite. Case modelling was (and still is) part of the ‘processing/BPM’ part of AppWorks. When OpenText introduces the entity building block principles into the AppWorks platform (in that time ‘Process platform’) they also introduced the lifecycle building block that made ‘Case Modelling’ closer and easier to the ‘low-code’ principles. So, the lifecycle building block is just a ‘Case Model’ and that is why we can also manage them with the ‘Case Instance Manager’ artifact.
The first thing we see is an empty screen
Let’s see if we can add instances to it!
Go to the front end of the solution and create a new instance of the entity where you included the lifecycle on.
After hitting that ‘Create’ button jump back to the CIM artifact and hit the green ‘refresh’ icon for the magic to happen…
Just click ‘the one’ for some more overview and detailed information!
You can right click to get more information, but you’ll end up with nothing as we don’t have assigned any tasks to the lifecycle now…remember?
Open the lifecycle designer again…
And extend to lifecycle to something like this:
Now we’ll add a task-form to the related lifecycle-task entity. Let’s open it!
You’ll see it’s just a brand-new ‘special’ entity with a full set of building-block.
Now create a new ‘Default’ form to it and add some task related information to it.
Go back to the entity overview and add a new layout building block to it with a name like ‘DefaultTaskLayout’. Make it a bit like this example, but feel free to add more information if the form is accessible, and the action bar is available!
Save it publish this ‘special’ task entity and close it.
Time to go back to the lifecycle overview (on our parent entity) as we want to ‘connect’ this new task-layout to our tasks!
First we’ll get the properties of our task…
And in that properties screen we can choose our crafted layout:
Do this also for all the other activities. We can just use that same layout for now…That is why we called it ‘Default’…duh!
Make sure all the activities have this nice icon applied to it.
Save it all and publish this entity.
After you created about 5 instances go to you ‘All tasks’ inbox and check out the result for some ‘Init’ tasks!
Open 1 of those tasks to see your layout where you complete the task.
Make sure to complete several tasks so you end up with several lifecycle status.
And now we get some more details
Let’s look at some ‘Activity details’
Where we can even dive deeper into the task details!
With this management console for this specific task where an administrator/manager can overrule the task actions…Great stuff, but handle with caution!
There is also a task history button available in the previous overview…
…that gives a detailed overview what was done on the task!
I played a bit with this action…
…and looked in the front-end, but it resulted in ‘Obsolete’ tasks…Indeed correct, but I was not able to remove them any more. They are also not removed after a delete of the case instance from the detail overview!
And I also couldn’t delete the entity instance anymore with this error as a result!
A view in the logging
sudo tail -f /opt/opentext/AppWorksPlatform/defaultInst/Logs/Application_Server.xml gives me more information to not use this action anymore!
It’s just ‘a new way of working with processes’!
‘Working with processes’ is also called ‘working with BPM’. A BPM process is a strict process that needs to be followed from start till end. So, it’s predictable and choices are made in the process (not the user!).
The new ‘Case Modelling’ (also called CMM) way of working is also ‘working with a process’, but it’s not called a BPM, but is called a ‘Case Model’. The difference is that it’s a more flexible way of working, it’s not predictable where it ends and in that case not fixed. The big advantage is that all the logic/choices are made by the end user that is involved in the process.
Both BPM and CMM have their own notation standards, called BPMN and CMMN.
This is a good resource for CMMN information: What is Case Management Model and Notation (CMMN)
For the overview a small table (just for you!)
|Naming||Business Process Management||Case Model Management|
And that brings us to the end of our post for this week with a ‘DONE’ we’ve earned proudly…good work and learned new information again! Have a good one and I see you in the next post on a new AppWorks installment.