Skip to main content

Dear Community,

We only use Universal GUI as GUI in our Production environment, and of course always look for ways to push functionality to our end users as fast and with as little downtime as possible. In that regard I would like to verify whether or not it is safe to do Sync to IAM without taking the Application down?

A couple of remarks:

  • I understand that for older GUIs the User session is actively terminated, this is not the case in Universal GUI.
  • I am talking about doing a Sync to IAM of the current Active project version in a Production environment. Example use cases:
    • After PROD deploy of new functionality we need to straighten up some UI or Roles issues
    • Simple User Interface-related changes requested by End users
  • The untranslated error message in the Universal GUI is not understandable for an end user, this should be fixed so end users actually understand that some functionality might have changed due to an update:
  • I just performed the following test (see below GIF):
    1. Login with a Test user
    2. Open ‘Add’ Form to add a record (don't save yet)
    3. Revoked rights for the user in the SF
    4. Sync’ed to IAM
    5. Pressed ‘Save’ in the Form with the Test user
      → Result:
      • Record is Saved successfully
      • Model is reloaded and Action buttons are greyed out

 

Except for the untranslated error message I feel pretty comfortable about doing Sync to IAM without downtime, based on these test results. Are there any caveats we should also be aware of?

I was kinda waiting with this question until after I would be able to test this expected feature, but just realized it's not there in Thinkwise Platform 2021.2 after all. If Sync to IAM can be done without taking the Application down I don't mind not having that feature.

Hi,

In that regard I would like to verify whether or not it is safe to do Sync to IAM without taking the Application down?

It is safe but the result is that the application model does expire as the model that the user has and the model that just have been synced is now different from each other. I do think that message still needs a translation.

Syncing to a production environment can be tricky as if you didn't first test the model you've just synced, it might lead to problems during use you would've encountered when testing the application. So yes, you can sync but without the proper testing it can lead to unforeseen results. 

Hi,

In that regard I would like to verify whether or not it is safe to do Sync to IAM without taking the Application down?

It is safe but the result is that the application model does expire as the model that the user has and the model that just have been synced is now different from each other. I do think that message still needs a translation.

We did some follow up testing today and have the following findings:

  • We noticed that for adding User rights the user needed to do a refresh of the entire application before seeing the changes. Examples tested:
    • Additional Menu items visible
    • Additional Detail tabs visible
    • Additional Edit rights on specific columns of a Subject
  • We noticed that for revoking User rights the user is capable of finishing the activity that was already started (like earlier posted GIF), but subsequent User-interaction actions fail → without need for refresh of the browser/application:
    • Edit > Save works, but Edit on other Row no longer works
    • Execute Task works, but subsequent Form after Open Document > Edit row no longer sets fields in Edit mode (record as a whole is put in Edit mode though, so Save button is activated)
  • We noticed that for an active user the sapplication_model_expired] could show up multiple times during the Synchronization to IAM.
  • We also noticed that for an active user the uapplication_model_expired] could show up a while later after the Synchronization to IAM, while navigating through the application
    • It is not entirely clear to us what triggers the message at what point during or after the synchronization.
    • I am tempted to say that ideally we only see this message after the Sync is finished, and that the message should recommend the user to refresh the browser/application.

Could you clarify what triggers the message?

 

Syncing to a production environment can be tricky as if you didn't first test the model you've just synced, it might lead to problems during use you would've encountered when testing the application. So yes, you can sync but without the proper testing it can lead to unforeseen results. 

Testing is a totally different topic than deploying without downtime, off course we would (almost :innocent: ) never deploy to PROD without proper testing. We can and will do a Sync to IAM to test environments first.

We are investigating the possibilities to get to zero downtime deployments with our AWS RDS & Elastic Beanstalk-based environment. Ideally we end up in a situation where we can push each individual finished User Story through our environments once approved, instead of having to do ‘large’ Releases. The Synchronization to IAM without downtime would be a small and simple first step. 

And in the same line of thinking the following is also interesting to know:

  • How about running IAM hotfixes without downtime?
  • How about running an IAM platform upgrade without downtime?

The [application_model_expired] message means the model itself has expired and the user should log out and log back in to obtain the new model. Changes in roles could have that effect.

Also Indicium may need a few minutes to use new rights on a loaded application as it loads the rights into it's cache/memory. UI changed (could also be caused by roles) will only be reloaded when the user logs out and logs back in. Maybe it would be desired that the GUI would automatically log out the user when the model expires but it can also lead to confusion.

It depends a bit on what the hotfix does. If it's a procedure on the database, then when you run the hotfix, no one will notice. If it's a model change, it's more impactful. 

Running a platform upgrade without downtime is probably not possible I think as procedures and such get dropped and created. These are needed for an IAM to be and stay operational.

The [application_model_expired] message means the model itself has expired and the user should log out and log back in to obtain the new model. Changes in roles could have that effect.

I understand the meaning, but I'm wondering at what point in time the message is actually triggered to show in the GUI. Is it based on Indicium's 1-minute refresh cycle which, upon noticing a change, triggers the message to be shown, or is it based on certain user activity in the GUI, or something else?

Maybe it would be desired that the GUI would automatically log out the user when the model expires but it can also lead to confusion.

Definitely a no on this one, it's great that we can do changes without interrupting user activity.

Running a platform upgrade without downtime is probably not possible I think as procedures and such get dropped and created. These are needed for an IAM to be and stay operational.

Never say something is not possible if we're talking about IT. Yes, it is a challenge, but there are definitely ways we'll try to get to zero downtime deployments for database changes too. But we'll treat IAM upgrades the same way as our own database upgrades to be safe.

Sorry for reviving this old topic, interesting thought!

The GUI’s load the model on startup. To enable upgrades without forcing the user to re-login, the client side model needs to be upgraded in another way, incrementally for example.

As long as the old version is still active, and datamodel changes are few, users can keep using the old model in their running GUI. Risky business though. If you did though, with custom code you could switch the preferred version of the application via User Preferences on logout, so that next login the user would start using the new version.

Once everyone is over to the new version, the old version can be disabled.

And in the same line of thinking the following is also interesting to know:

  • How about running IAM hotfixes without downtime?
  • How about running an IAM platform upgrade without downtime?

On my second question I can share an experience of last week: we upgraded IAM to 2021.3 without restarting/recycling the Indicium server (since our Indicium and Universal GUI were already running on a 2021.3.X release). This caused all kind of errors with System Flows, since the Data Model and logic for System Flows was changed with the IAM upgrade.

Lesson learned: it is currently needed to do a restart/recycle of Indicium after an IAM upgrade.

Sorry for reviving this old topic, interesting thought!

The GUI’s load the model on startup. To enable upgrades without forcing the user to re-login, the client side model needs to be upgraded in another way, incrementally for example.

As long as the old version is still active, and datamodel changes are few, users can keep using the old model in their running GUI. Risky business though. If you did though, with custom code you could switch the preferred version of the application via User Preferences on logout, so that next login the user would start using the new version.

Once everyone is over to the new version, the old version can be disabled.

@Boudewijn Interesting idea! A couple of follow up questions come to mind:

  • What would happen to an Active User session if we would do a Sync to IAM for a new version, then Inactivate the existing and and Activate it after Sync is finished, while User session remains active the whole time? That would save us the custom logic → I could/will test this another time myself
  • As far as I know none of the User Preferences are currently supported for Universal GUI, I guess we would have to wait for that to get this solution working?
  • A lot of our User sessions don't have an End Date in the Session Log, how do we recognize that a user is actually logged out/inactive?

Reply


Terms & ConditionsCookie settings