Offline Feature

Product Suggestions
1

An option should be made available to operate Tulip offline so Production does not have to stop. This way at a later point admins could upload data whenever the connection is restored.

There are use cases when a site can have outages due number of reasons (e.g. service provider, hardware,etc).

Regards,
Jorge Jimenez

2

Hi Jorge,

I’m really curious about this use case. can you tell me how often an internet or wi-fi outage happens? When’s the last time internet went down? was it planned or unplanned? and how long was it out?

and were some workers still busy during the outage? or was the site effectively shut down?

thanks
Sam

3

Hi Sam,

Two scenarios that come to mind, one is for a customer we supported recently that started to use Tulip and they have told me there are areas at the mfg site where wi-fi is a problem so there are times when they loose connectivity during work hours making it difficult for operators to perform day to day activities inside of Tulip. Second scenario I’m thinking of is within large corporations with big IT groups. I used to work for a company that had a PLM system that from time to time was down due IT quarter maintenance, hindering the ability of operators to access work instructions over the weekends so an offline option during this time was made available.

We can meet if needed to talk more about this topic.

Regards,
Jorge Jimenez

4

Thanks for providing the context. This is something we get occasionally requests for, but is technically challenging to implement, so it tends to get prioritized behind other work. I created ticket PLAT-10579, for reference. It’s in a place where it won’t get lost, but it’s also behind about 8 other major work items to improve the Tulip Player, to try to manage expectations on timeline.

5

Tulip basically uses web technologies.
Wouldn’t a possible option be to store the process in the LocalStorage or even the IndexDB of the browser after completion.

A loop with an interval could try to repeat the operation until it worked.

Example for my usecase would be:
WIFI not work, but the application can still be used.
User enters all information in the fields provided.
After completion, this data is sent to the DB via the SQL connector.
If this fails, then one could save this transmission and try again later.

6

Hey @jajzler -

This is something we often talk about the right approach to. There are many usecases (including yours) where a completely offline mode is possible but MANY different little reasons why an app couldn’t be used offline:

  • Keeping track of authorized users without an internet connection becomes quite challenging. SAML/SSO can somewhat resolve this, but many customers just use the built in Tulip User functionality. What if a user is fired but a production station on the floor cant see this change and lock that user out of Tulip.
  • Any connectors to the outside world wont work. This often includes stuff like REST API connectors to ERP systems, LMS systems, and more.
  • Any shared data between apps cant work. One of the most powerful features of tables is the ability for multiple stations to be working on the same table, at the same time. This wouldnt be possible (in most cases) with an offline mode.
  • New versions of apps wont be automatically downloaded on stations, this can be a gigantic compliance issue
  • There are many many more…

The approach we would probably take for this would be to designate an app as an offline compatible app (either before it is created, or after it is created) and certain features wouldn’t be accessible (like sending emails). Along with this we would probably need a mechanism to make a Tulip Table Read-Only or Write-Only. Read-Write is where tables wouldn’t work online. For a lot of use case RO and WO would be adequate (including yours). Additionally, we would need to come up with a bunch of new tools:

  • A mechanism to get apps deployed to offline stations without internet.
  • A mechanism to view see if there were any issues in the back population of data.
  • A locally stored SSO parallel hosted to get around user management limitations without internet
  • Probably more.

Like Sam said. this is certainly something we want to tackle eventually, but it is currently not an area of engineering focus.

Thanks for another example usecase for offline!
Pete