/ Development  

Your guide on creating a 'Dynamic Enumerated Text' property

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

And this time we take a deeper look on the ‘Dynamic Enumerated Text’ property. In a previous post we already created an ‘Enumerated’ property, but we only used the ‘static’ variant. This made it possible to select a value from a static list of items that we could low-code on the property. Would it not be nicer to update the property with a dynamic list of values? That is exactly what we will cover in this post.

Make a note that a ‘dynamic’ variant of the ‘enumerated text’ property works the same way for an ‘enumerated integer’ property!

Let get right into it…

Spin up the VM and open the ‘Explorer’ with our developer user. Enter your beloved workspace, open the project and enter our crafted ‘entities’ folder.

We now open the ‘Member’ entity where we already have available our ‘Enumerated text’ property with the name ‘mem_role’ that looks at the moment like this.


Let’s see if we are able to create a ‘dynamic’ version of this property…and…make it an ‘enumerated integer’…I know…It’s not in the post description, but we do this also to see what happens and learn what else will break!

Let’s first delete this property.


It might not be a smart thing to remove this property and create a new one with the same name with a different type, but we’ll see what will happen!? And otherwise we’re here to fix it! 💪

After this delete it’s a logical thing to publish the ‘Member’ entity again. When you refresh the ‘Member’ list in the front-end you will see that the ‘role’ column is gone and that also the field is removed from the ‘Create’ form also…It’s magic, but it’s also a good thing to know for your production data!!

It’s not only the front-end that is updated also the building blocks are updated with this delete action. So, of course the front-end is cleaned with that publish action we just did!

Now create a new ‘Dynamic enumerated integer’ property with the name ‘mem_role’


Select the property in the list and then we see something nice that we can create…a BPM…And what kind of BPM…from a template!…ooohhh…What magic is behind that plus-sign!?


Hit is like a pro…


Select ‘No’ and hit that shinny button ‘Create new process’. The other option has to do with ‘Conditional values’ where 2 properties depend on each other. This makes it possible to create 2 dropdown lists where the second dropdown is populated with values based on the first selected…Trust me…you want to know how it works…It’s on the backlog so we create a separate post out of it.

This is what we get back:


Save the this with a name like ‘getMemberRoles’ and make sure to save it in the ‘bpm’ folder!


Now what?

You probably saw the ‘envelop’ icon in the final red circle. Get the properties and see that a ‘special’ message is created here…The ‘output message’ and I think it’s time to get the output message filled with some roles (labels + integer-values).


Why the ‘Activity’ in the middle?

It looks like 1 activity is required to put the start and finish together…But we’ll see. We could replace that thing with a webservice call that retrieves the roles from an external source…not for now, but you get the point.

Also take a look on the properties for the whole BPM model


Take note of the ‘namespace’ URL…Just remember…because you can!.

Now switch to the ‘Message Map’ of the BPM and select the ‘green Start’ activity


Now it’s time to add the correct message (with all our data) in the ‘GetEnumerationOutputMessage’. For now, it’s static, but it could also be retrieved from a webservice.

Make sure to select the correct action:


And past in this XML data.

<GetEnumerationOutputMessage xmlns="http://schemas/AppWorksTipsAppWorks/member/enumeration">
<EnumerationValue xmlns="http://schemas/AppWorksTipsAppWorks/member/enumeration">
<EnumerationValue xmlns="http://schemas/AppWorksTipsAppWorks/member/enumeration">
<EnumerationValue xmlns="http://schemas/AppWorksTipsAppWorks/member/enumeration">

You see that this data is almost the same as we can create with a ‘static enumerated’ field, but we miss one thing…what would it be…exactly…The ‘Icon’! Too bad for now…maybe a feature for the future?

Save the process, ‘validate & build’ with <F9> and publish it.

Before we can start testing we need to do an extra step. As the old property is removed from the ‘Member’ entity, the ‘Create’ form and maybe other forms you created as also the ‘List’ building block is changed. So, both need to be updated with the new property!

What I noted in the List building block for the entity is the next thing. When you use the ‘dynamic enumerated’ property you are not able to select another ‘column presentation’. That is also in relation with the missing ‘icon’ feature…Maybe ‘dynamic’ is not as ‘dynamic’ as we wanted!

When done…publish it all and…

…do the end-test.

Enter the front-end /app/start with a ‘normal’ user. In our case ‘awuser’. You can already view the ‘AllMembers’ list, but the ‘Role’ column will be empty for the current created ‘Member’ entities. Now create a new ‘Reviewer’ and see your new ‘Dropdown’ populated with the valued data.

Maybe it’s my environment or playing, but I needed to do a ‘rebuild’ of the project to get the new results in place, but I also tried several things before I came to this end post. What I do see during my journey on AppWorks is that BPM is not always as close connected as the ‘Building block’ principles. This is also the first time I see caching things happening on the AppWorks front-end!

And…That is a well delivered ‘DONE’ on dynamic enumerated properties. Great functionality, but as greatness is introduced also consequences are introduced. We saw how it works and now it’s up to you to make the most valuable interaction with external systems. Have a great day for the rest of today and I see you in the next post.

Don’t forget to subscribe to get updates on the activities happening on this site.