Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Long, long time ago we created a post about ‘conditional value assistance’ between two dependent entity properties. A splendid feature was explained, but with new insights from my own experiences we can do a better job! Keep on reading to consume the good stuff of the platform…

Let get right into it…

A short recap from the mentioned post where we implemented this taxonomy with the help of a ‘Decision table’, but this post uses a webservices approach:

• prio_1
  • bug
  • release
  • test
  • package
• prio_2
  • release
  • test
  • package
• prio_3
  • release
  • feature

The priority level of this taxonomy was (in the old post) a static enumerated list, but this post makes this first level also dynamic and reads a ‘Taxonomy’ entity from the applied ‘Web services’ BB.

Let’s dive into our ‘Workspace Documents’ artifact with related workspace and project. I have an ‘entities’ folder available where we create a new entity with name ‘taxonomy’. Add two ‘Text’ properties like this and make it all nice for a first deployment:

You can make the choice to create both properties of type static Enum, but with ‘Text’ we are flexible for the future. We can make this entity only available for administration people which limits typos in runtime.

In runtime, we can now create our tree:

Next step is to add the ‘Web service’ BB with two ‘find operations’…AllTaxonomies and AllTaxonomiesByPriority. That last one has an input parameter priority configured like this:

You can create the parameter in the ‘Parameters’ tab!

At this moment (and after publication) we can evaluate both services from the ‘Web Service Interface Explorer’ artifact, but (as you all know by now) we can only make this work with a configured service container of type ‘Application Server’…You know the drill from the ‘System Resource Manager’! Comment me for guidance…

A service request on AllTaxonomiesByPriority will eventually look like this:

1
2
3
4
5
6
7

<SOAP:Envelope>
  <SOAP:Body>
    <AllTaxonomiesByPriority>
      <priority>Priority 1</priority>
    </AllTaxonomiesByPriority>
  </SOAP:Body>
</SOAP:Envelope>

With this result (cleaned for readability):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<data>
  <wstxns1:AllTaxonomiesByPriorityResponse>
    <wstxns2:taxonomy>
      <taxonomy-id>
        <Id>1</Id>
        <ItemId>08002759e511a1ecbf440ca70c2fb42a.1</ItemId>
      </taxonomy-id>
      <tax_priority>Priority 1</tax_priority>
      <tax_type>Bug</tax_type>
      <wstxns3:Title>
        <Value>taxonomy-1</Value>
      </wstxns3:Title>
    </wstxns2:taxonomy>
    ...
  </wstxns1:AllTaxonomiesByPriorityResponse>
</data>

Great, works as expected…Time to use this information on a new entity with 2 dynamic Enums which relate to each other. Also known as ‘Conditional value’ properties.

Create the second ‘todo’ entity

Same exercise as above, but with new input:

Notes:

• Name the entity ‘todo’ with label ‘Todo’
• Those 2 properties are of type dynamic Enum (continue reading)
• Make all the other BBs “nice and cozy”

With this first (unpublished) step, we add new BPMs to both the dynamic enumerated properties (see the red-arrow from above!)…The todo_priority will get a BPM without any input message (only output); todo_type will use the other option (input and output!)

After generating both BPMs, we save both of them with names like bpm_get_all_priorities and bpm_get_all_types_by_priority. We also save them nicely in the bpms folder of the project. At this moment it’s still not possible to fully deploy the project because of a missing input property-name match on the bpm_get_all_types_by_priority BPM. Watch and learn:

Request for OT: Make the input property selection available on that BPM creation screen!?

Now we are able to publish the project again without any errors…

…

Always a forgotten feature is the ‘Cache refresh’ for our Enum properties…Have a logic value and keep performance in mind!

…

Next step!

BPM implementation

From a runtime perspective, we can now create ‘todo’ instances. Only, the dropdowns are empty! Why? Well, our BPMs don’t return any entries in the output message…That’s why! Time for some implementation on the first BPM bpm_get_all_priorities. Right-click that one activity and insert our entity webservice ‘AllTaxonomies’ and we further extend it with a loop like this:

Notes

• Create the “For-each” loop box with a right-click on the activity!
• Make sure you connect the arrow-flows to the loop (instead of the activity)

Provide a solid name for the internal iterator name like iterate_taxonomies in the properties of the loop. Also select the condition of the loop on what element to loop over (the output of the ‘AllTaxonomies’ service call!)

Now we’re left with some message mapping magic…Jump to the corresponding tab for an implementation. Here we first make sure to create a new bpm:Local element. We use this element as temporary safe-haven before adding it to the output message…Sounds hard but is not that hard to do! What do we need in the output eventually? Well, new elements with name EnumerationValue and the structure below it! So, make sure to grab a copy of the XML:

Copy the XML-part and paste ‘XML as Element’ into the new bpm:Local element…This is your end-result:

Time to “messagemap” the activity ‘Add to output message’ where we first fill our temporary variable and add the variable eventually to the output message. This is the consolidated view (where ‘target’ and ‘source’ are rotated 🙃) of how you would do such task:

Notes:

• Make sure to use the ‘Iterator’ to grab the value!
• ‘IsDefault’ can get a static value of false
• Keep note of the ‘Use’ type, so switch from ‘Replace’ to ‘Add’ where required
• Use the correct elements from the source/target

After a publication, we see our first result in runtime:

Haha…I see my dropdown is collapsed again during the screenshot! Trust me…The values are there! 😇 Looks like I’m still human…Lucky me!

NICE! 😎 NEXT…Well, how hard can it be? Same principle, same idea, only with input this time! So, I’m not explaining it all again, but let’s focus on the extra effort and the consolidated end-result for the message map!

• The BPM itself ‘looks’ the same at activity level, and flow level (only with an extra input message!)
• Our webservice call is now AllTaxonomiesByPriority
  • See the consolidated view below for the extra message map update!
• Add the ‘Local’ variable including that XML-part

Well…Where are you waiting for…let’s publish and evaluate the outcome in runtime:

Ohw Yeah……!! 😍 Shining bright like a diamond! 💎

“DONE” my friends…How easy can it be! Wasn’t this a great low-code example of a best practice to implements dynamic enumerated lists. It won’t get more low-coding then this, and now you also see the power of BPM for the most advanced features. There is more beyond the entity modelling principles and this is typically one of them. Time for you to consume this information into your own projects…While you’re doing so, I’ll focus on another great AppWorks topic for next time. Have a great week-end…cheers!

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”?