I’m just on the way to go further with the APP versions. We want to publish the new APPs so that the workers in the production can finish their jobs with a stable APP, while we developer continue to design new features. However it makes troubleshooting impossible. In the past if a worker has seen some errors during the job, we build a Text in their app immediately to see the results of the connectors, records, etc, so that we can understand the error easily. This option is unfortunately not possible anymore in the published version. Are there any other ways to realize some kind of debugging in the production environment? I have searched some topics like event log or debug over console, but nothing found for this requirement.
Would running the development version of the app on a test station help in this situation? The development version would be identical to the production app but you could add in debugging steps like you mentioned and run it in player at a different station than the production station. If the data needs to be separated, you could do this in a separate workspace or a separate instance like many GxP customers do.
I have also thought about running a dev version on one test device but running the stable published one on the rest stations. However our problem is, the errors appear randomly but not so frequently. It won’t be enough to just debug on one station as we want to understand the errors when they appear in the daily production, due to e.g. wrong input data from SAP. Those conditions are hard to simulate…
Would it be possible to add a dev mode to the published version, so that we developer can still do some changes live to the station via some kind of button/switch? Or is it possible to support two dev versions, one for the live debug and one for the further development?
I hope I have clearly explained our user cases. Definitely I’m talking about the implementation in a non-GxP environment.
@HCZuo it was nice to meet you in Community Orientation the other day
I wonder if the root issue here is related to this long standing product request around having more robust error logging in Tulip? Event log to record Tulip error messages
If you think this would solve your need, go ahead and vote on that request!
If your preferred solution here is having the ability to test published apps without affecting the published app itself, I can make this thread into a separate product suggestion for the team to consider.
@Beth Yes I have voted on this feature reqirement as well!
From my perspective, in order to debug the APPs several solutions are possible:
a. offer the error message in the log files so that we can retrieve afterwards what was happening in the APPs.
b. still leave a backdoor for the published version so that the developers can dive into the APPs to see how the error occured. At present we just define new widgets in the APPs to see the value of variables (that is why we can only use develop versions…). Definitely the console can show this info as well (similar as call stack in Visual Studio).
I suppose either will work for a better version control.
