As is best practice, segmenting software with interface layers is a great idea to limit the complexity of each individual building block. We are attempting to port this software best practice into how we build our tulip apps, but we have run into a fairly major impediment.
We have multiple different positions on the floor that use the same tulip devices, but for very different use cases. For example, A mold tech will go to the machine and start the job up, then they will pass the job off to a finishing operator that has very different needs from the app, finally a coordinator might come over to the press again and have a different set of needs. The logical way to do this traditionally would be to segment these needs into individual blocks that can be passed back and forth between as there are different needs for each position.
This is where we have run into a current limitation of the tulip platform, we can’t elegantly do that handoff between apps.
As one app transitions to the other all of the app variables are wiped clean and the first app is completed, now in the new app, we don’t know what order (or any other information that we need) was running in the last app.
A solution, but not a good one
There is a bandaid that we have implemented, but it is pretty tedious. We store a record based on the station name with a small set of handoff data referenced by both apps. so the flow goes-
- App 1 populates handoff into record with the id of the station name
- App 2 loads that record based on its station name
- App 2 saves table variables to app variables to use them
- App 2 does stuff
- App 2 saves data back to handoff
- App 1 loads data from table
- App 1 sets table values to app variables.
This isn’t an elegant solution, really limits the amount of data we can pass because each field needs to manually saved to that handoff table, then loaded back from that table. The complexity of this solution also opens us up to a lot of risk of potentially incorrectly mapping any variable in any of the 4 different remaps that need to happen.
This leads us to building these monster apps that have 75+ variables and all the job functions included in their functionality. this isn’t best practice.
My Proposed Solution
Allow apps to passed between with optional attributes. Add an option to the transition menu to “load an app step with attributes”.
This will require that the receiving app sets a protocol of how it expects the data, I see this as the largest complexity adder to this solution. Potentially this could be addressed with a new type of connector function. So I could create a “Mold Tech to Finishing Operator” connector function that defines what parameters are expected, and what datatypes they are.
These connectors could be added to the transition, and the required parameters could be assigned.
How this would help everyone
- Apps could be significantly simpler
- Apps could be improved without risking the stability of others
- Troubleshooting issues is much easier with smaller apps
- Less tables.
- Much more intuitive handoffs. Right now it takes a very experienced tulip builder to understand how this workflow works, connectors would require more upfront work, but would really simplify the logic.