Conditional refresh mechanism, for embedded HTML scenarios

Hi Harm,

Did you mean to create an Idea for this? This sounds more like a ThinkStore entry - but then it misses the solution 

Hi Mark, 

This is the outcome of a chat with Anne Buit, yesterday during the ISV session.

It is an idea for a small addition to the Thinkwise GUI's to enable better integration of embedded pages.

Hi @Harm Horstman, 

Have you been able to solve this with the new change detection mechanism?

Good morning Jasper,

You make me curious. I didn't know such a thing existed already.

From which version is this available and does it also work for the Windows and Web Gui?

Hi Harm, this is what I'm talking about:

• Release notes: 2022.1 | Thinkwise Documentation (thinkwisesoftware.com)
• Documentation: Logic concepts | Thinkwise Documentation (thinkwisesoftware.com)

Change detection also works for the Windows and Web GUIs.

Jasper,

It seems that this is exactly what is needed. If I can get this to work, we can make a big step forward.

The documentation says it's also possible to trigger this via an API, but I just don't see an example of what the API request should look like.

Can the creator add a little more explanation to the documentation?

Hi Harm,

The change detection logic (stored procedure) can indeed also be called via the API, but that will rarely be necessary.

The logic is automatically called by the GUIs for tables with auto-refresh enabled and the change detection option checked.

Hi Harm,

Triggering it would be something you can do yourself by writing the logic of the change detection according to your specs. For instance, you can let a task update a modification date that will cause change detection logic to return true on the @refresh_data variable.

The documentation does state that you can call change detection via the API.

Assuming a BASE URL that looks as following:

https://[incicium]/[meta]/[product]/[resource path]

For a specific variant, detect change after a certain UTC date:

GET [BASE URL]/detect_change(variant_id='[variant_id]', last_refresh_utc=[last refresh])

For a specific variant, detect change without supplying a previous date:

GET [BASE URL]/[resource path]/detect_change(variant_id='[variant_id]'])

For the base table, detect change after a certain UTC date:
GET [BASE URL]/[resource path]/detect_change(last_refresh_utc=[last refresh])

For the base table, detect change without supplying a previous date:
GET [BASE URL]/detect_change()

Variables:

• [indicium]: The indicium url
• [meta]: The meta carrier, practically always iam or sf.
• [product]: The alias or id of the application (when using iam) or runtime configuration (in development when using sf)
• [resource path]: An entityset, directly or via a navigation path. e.g. invoice or customer(13)/detail_ref_customer_invoice.
  • This determines the input values of the logic, similar to a badge.
• [variant_id]: The variant, I think this speaks for itself
• [last refresh]: UTC date to base the change detection on. ISO 8601 - e.g. 2022-02-11T11:11:49.965Z

The idea has now been made possible by using the 2022.1 release of the platform in combination with the Universal GUI from version 2022.1.11. The Windows and Web GUI support this functionality since 2022.1.10.