Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
Have you ever wondered why a developer built a certain functionality as he/she built it!? Sometimes things “feel” and “smell” very strange, but when you start to unwrap the functionality with a solid implementation you directly hit the wall of reasons why that “something” was built like that in the first place. What I try to say here…it’s not always the developers fault crafting a certain functionality. Sometimes it’s just the limitations of the platform! I leave the discussion (if it’s a bug or simply the way it’s working) with you but let me show you in this post how nasty something can get when you need to build a workaround which you would expect to behave by a logic thinking process.
Watch and learn…You can have the discussion during a coffee break at your own location! 😱
Let get right into it…
Dive into you design-time URL of the AppWorks platform with your developer account. Open (or create) a workspace with relative project and craft yourself a nice ‘Case’ entity with whatever you can produce. Make it steady with the correct building blocks and naming conventions. Once ready (incl. a nicely crafted ‘Create’ form), add also the ‘Lifecycle’ BB with a first implementation like this:
If you don’t have a clue how to get till this point, I suggest you first go to the “products” section of the website to learn about the free basics first.
I also update the default layout with an extra ‘Progress Bar’ and ‘Tasks’ panel to have an instance up and running in runtime (after a publication) looking like this:
Complete task ‘Activity1’ and complete the next ‘Activity2’ task…Regular stuff; nothing fancy!…right? Well, let’s now update our lifecycle with an extra BPM call; Like this:
So, after completing ‘Activity1’ in runtime, our BPM bpm_dummy (which is just a 1-activity long-lived process) automatically fires, and we land magically in ‘State2’ with a new task ‘Activity2’ to complete; Do we expect anything special in runtime to happen? Well, I don’t! BUT have a look how the confirmation screen gets an extension with nonsense information of our BPM trigger:
That’s bringing techie-stuff at the end-user for no reason!…How can we fix this? That’s a quick workaround like this in the lifecycle implementation:
Try it out yourself and conclude the task nicely completes without any nonsense information AND check the PIM for a new BPM instance doing your advanced logic implementation. Now you tell me…Is it a bug or is it a feature!? Have a comment below…
Now you see that it’s not always the developer messing things up in a solution; Sometimes the platform is against you! To make it clear, I would add an annotation for other developers on this chosen workaround with the reason.
Great, a well-earned “DONE” with an interesting workaround explained. Make your own conclusions, but now at least your end-user isn’t involved in the discussion. This post was just a simple practical implementation we do at projects at our customers. Pick the fruits, share the thoughts, and I see you in another great topic at AppWorks-Tips.com…Ohw, and have a great weekend! 😉
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”?
