Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
An interesting topic again; a trap we all fall in. It happens silently and always explodes when the tensions are high. I’m talking about project dependencies and more specific the circularity between projects. A dependency is when project A depends on project B; Circularity happens when the project B depends also on project A. We’ll make an example, so don’t worry. I’m always a proponent of the Single Responsibility Principle (SRP); It’s one of the SOLID principles in programming. Guess what! Our beloved AppWorks platform is a low-code platform, but that doesn’t mean you just do whatever you want/need to do! Think, then act! At all costs, you would like to avoid dependencies, or you must a have a good reason to put it in place. This post shows how you create then, how to detect them, and how to avoid them. 💪
The post has three sections where we move from step to step and see the struggles we’ll face during exploration. We also create a circularity example that will remind you that you chose a wrong path in the past. Maybe intentionally, but mostly unintentionally.
Let get right into it…
Boot up the VM and jump into your favorite workspace and related project using your developer account. As we’re talking “project dependencies” here, we first create a second project in the current workspace. Name it whatever you want; This is my current view:
In our “general” project, we now create a new ‘Entity’ type of document in the ‘entities’ folder. Keep it a simple ‘Case’ entity with regular properties for you to play with; This is my view:
You see my naming conventions applied, a bit of properties fine-tuning, and a nice ‘Create’ form…Do whatever you need to do! #YOLO 🙈
…
Now right-click the ‘Case’ entity from the project perspective again and create a new subtype out of it. You will see this inherits most building blocks (not all!), name the new entity ‘Case special’, and do a ‘Save’. It’s now saved in the “general” project, but when you go the properties of the new entity you have the option to move it to a different location! That will be your new project location:
Guess what the new location will be? Yes…prj_specific/nl-bos-specific/entities
You can also drag & drop the entity…In case you wondered.
Looks to me our first dependency is in place! Now for that question: Do we have a good reason? Well, I would say YES! This means we always need to deploy our ‘prj_general’ first (or have it deployed already) before we can even deploy ‘prj_specific’…Just that you know.
Detect the dependency
A great question…How can we detect this created dependency? Well, right-click the project ‘prj_general’ and use the action “Used by”…
This is the expected result:
So far, so good on the intentionally crafted dependency!
…
Let do it the other way around…Create a new ‘List’ BB in the ‘case_special’ entity with name lst_all_cases_special and add properties of the parent entity (a simple task…right?). Save it and move back to the general ‘case’ entity. Open the layout ‘lyt_default’, add a new ‘Results’ panel, and select from the list the just created ‘lst_all_cases_special’! So, like this:
Now right-click the project ‘prj_specific’ and use the “Used by” action…Now you see the “generic” project has a dependency on the “special” project; Again, you can raise the question: Do we have a good reason? Well, in this case I would say NO!
Can we do it different? Well, in this case we can! The ‘case_special’ entity instances will also pop up in the ‘All cases’ list and in runtime you can filter them out! AND save it as a new filter (since the latest platform versions):
If you wonder where you can find the ‘Entity type’ filter. I added it to the ‘lst_all_cases’ list as filtered option:
A circularity example
Well, if you paid attention, the circularity was already in place! Let’s go back to the ‘lyt_default’ layout of the ‘Case’ entity and select again the ‘All cases special’ as list for the ‘Results’ panel (which creates the dependency again if you removed it already to make it work with the filtering of the previous section). With the dependency from “General” to “Specific” in place, do a publication of the projects and come to a devastating conclusion:
This error is your worst nightmare that you must avoid at all costs!
…
Let’s dive through a quick list of potential scenarios where you have…
- A ‘History’ BB on the general case with a selected history log on the specific case
- An ‘Email’ BB on the general case with a selected email config on the specific case
- A BPM in the general project using a webservice (any of the CRUD operations) of the specific case entity
- Another BPM in the general project with a runtime security using a role (of any type) of the specific case entity
So, be aware what you’re doing and 👀 your dependencies carefully!
That’s a “DONE” where we learned about project dependencies, how to detect them and how to avoid them. A skill required to make sure you don’t hit the wall once you’re in production, and you can’t get rid of the dependency. Again, one step closer in increasing knowledge, one step closer in being just a little better. Keep it focused here to learn more about the AppWorks platform. Have a great weekend and CU next week.
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”?
