Swapping between apps - Starting apps with parameters

Product Suggestions
1

Hey all,

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.

The Problem
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-

  1. App 1 populates handoff into record with the id of the station name
  2. App 2 loads that record based on its station name
  3. App 2 saves table variables to app variables to use them
  4. App 2 does stuff
  5. App 2 saves data back to handoff
  6. App 1 loads data from table
  7. 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.
4 Likes
2

Wow, this is very intricate and well thought out. Good ideas here.

We have talked about something similar internally. One of our major concerns is exactly what you mentioned- this will make Tulip apps more scalable, but also increase the learning curve and the complexity to get started.

I think the solution needs to be independent of stations, as you suggested. Because, in high mix environments, there are many products with some common processes and other distinct processes. The product is built over multiple stations, so you would still have this problem, but instead across multiple stations.

You would want to turn each app into a ā€œmicroserviceā€ that operates independently.

Also, different companies may do different parts of the process in other systems.

For example, some companies create their work orders from a Tulip app, and others feed them in from SAP or another system.

I am wondering if it could be done natively in apps without asking users to understand multiple features to get started? There would be an ā€œinputsā€ section of apps that would allow you to map values to variables when the app is started.

Then, when the app is started, you might have a trigger that is like ā€œLoad Dataā€ and allows you to select an app and a recent completion by operator or by timing or by station. Then you would be able to select that previous appā€™s variables and map them to variables in the current app that were predefined as ā€œinputsā€.

3

Hey Kevin,

In thinking on this more last night, I think you are totally right, building the loading of inputs into each app is probably the right approach as opposed to a connector parallel.

With connectors now you would have to support 2 different ways an app could be started (what do we do if the app is started from the connector versus from the app selection menu?). Suddenly that gets confusing because in testing now the ā€˜Runā€™ button on an app may act differently than when the same app is loaded from another app.

Even if there was a special step type, similar to a form that was always locked as the first step in an app, within that step you could assign all the variables needed to start that app. This step could be toggled if you were only running a single app and didnā€™t need a dedicated set of inputs to shift between apps. When an app handoff is called, you could assign values to that action in the trigger, and the app you are transitioning to would automatically skip that input step if the values had been passed.

This would mean when hitting the ā€œrunā€ button you would see the same behavior as if you transitioned from app to app (going to the input setting step), and would allow the greater scalability we are desiring.

Iā€™m not too sure of the implications on companies that use different systems for different parts of their process, but I could see this being a huge enabler potentially - No more copying the order information between your mes and your app, now that data can be passed directly into the app when it is started.

I think your engineering team is in a tricky spot because you are trying to make a product you can learn quite easily, but also doesnā€™t make complex functionality exceptionally tedious. I think this would fall into the category of ā€œMakes learning Tulip harder, but enables better app architecture, and ultimately a better experienceā€ .

Thoughts?

4

So two thoughts on this particular idea:

  1. We currently handle connector functions very differently than record placeholders, even though they are analogous concepts. If you could define the way a connector function shares data at the app-level rather than the trigger-level, then those connections would be a lot easier to view and manage. Then, you could easily define the connector function ā†’ app connection and then tie that into values within the app. So it would be obvious to an app builder whether a connector function is supplying the work order values, or it would need to be manually defined by the user.

  2. To your point about sharing data between apps, I would say that the current ā€œRecord Placeholderā€ concept is the first example of an ā€œInputā€ but to make this work, there would need to be others. For example:

  • Variables
  • Connector Function Outputs
  • Machine Data, perhaps

As for the challenge of powerful features vs. simplicity to learn, that is why we are excited to do our jobs every day! As we are discussing, it requires really good discipline around each ā€œobjectā€ in Tulip - connectors, apps etc. so that the use case for each one becomes obvious.

2 Likes
5

This has been hanging out here for a long time, but I just noticed it and wanted to give it an upvote. The typical workaround for this is that the first app writes a record to some table, then the second app looks for that record. As a software developer, this rubs me the wrong way because itā€™s loaded with concurrency issues.

An App already has access to an App Info object. Adding another field to that wouldnā€™t be disruptive to existing apps. The thing thatā€™s missing is ā€œCall App with Parameter.ā€

One simplification Iā€™ll offer is that I would be OK with the parameter being just a single string. If you want something more complicated, you could then just use a table but generate an auto-ID for the new row, and pass that auto-id to this new Call App with Parameter action.