Questions & Answers

[siba]

Hello,

The customer wants to create a page that is only to be displayed on the web server at a specific point in time. The customer would like to be able to set the time in the CMS.

Walter from the support gave me some links, that I have checked, and he meant I should ask in the community.

I have taken the suggestion from mr. Höbbel in one of the postings and start to write a concept, now I have a question.

I thought I set a date input field for the editor in the metadata, this can be asked in a script e.g. check-date, and in a workflow I add this script to an activity.

When the date >= current date then this script should trigger another transition to an activity "Freigabe" with another script, this script e.g. trigger generation, should start the full generation. 

Now is my question, in the first script check-date, I need a loop for comparing the date (out of metadata) with the current date. Is this possible and does not affect the performance? Particularly when the date in the metadata is far in the future?

Or is there an other solution?

Thanks for your input.

Best regards 

Silke 

[hoebbel]

This is not a good idea in my eyes. Apart from the fact that the workflows would always run on the nodes, a server restart would cancel the workflows at the latest.
Depending on what is desired, I would proceed like this:
If only to make sure that corresponding nodes are considered in the next deployment, I would run a script before the generation action that iterates over the nodes in question (e.g. pagerefs) and check for all never [or not?] released ones if there is a corresponding date in the metadata and then releases the nodes accordingly using releaseOperation (Attention: wait until the operation is done and afterwards set the execution date of the schedule entry to the current date, otherwise the changes will not be considered). Also, I would additionally reset the date within the metadata so that the node is not accidentally released and published automatically after the next change.
If manual control is desired (or the project is too big for a full iteration), an editor could for example run a workflow on each node in question, that stores the required information (node to be released, date of release) somewhere (e.g. in a database table). Then query this location via a script before the generation action of the schedule entry and release the nodes accordingly. (and ideally mark/delete the processed entries accordingly).

Note: I would personally use the second approach (both for performance reasons and because of the possibility to centrally see which time-dependent releases are pending).

Note: If it's not about completely new page references, I would use the validity period (visible in SiteArchitect on page references). There you can switch at which time another page should be played. When using this feature, however, you should create a new revision in the project before each generation. (english link to the same topic)

Best regards
Holger

[siba]

Hallo Holger,

you are writing:

--> Then query this location via a script before the generation action of the schedule entry and release the nodes accordingly

But how can the schedule entry be triggered at exactly the time the editor has choosen?

Best regards

Silke

[hoebbel]

Hello Silke,

I had assumed a regular generation, which checks in each case whether something must be released.
If it is about exact times, then I would use a PWA in the front end and simply transfer the information from when a page should be available.

If static pages are used, then I would suggest to use a workflow that creates a schedule entry via script that should be executed at the appropriate time. (the disadvantage here are the times needed for generation and deployment). This workflow needs a script, that asks for (or reads) the appropriate release date and then creates the schedule entry for this date.
Or, if a few minutes doesn't matter, you can simply run a regular job (e.g. every 15 minutes)
You have to store the information somewhere within the project (e.g. as a database entry - this makes sense, if more than one node may have to be published at the same time) or (if a schedule entry for each pageref is used maybe within the schedule entry, e.g. as start nodes of a fake generation aktion).
After reading the information you have to release the appropriate nodes.
Afterwards (and after resetting the execution date of the schedule entry to "now") I would calculate a delta generation, so all needed start nodes are put to the generation action. If you already use delta generations within the project, you should reference the appropriate script.

best regards
Holger

Annotation: these are just some thoughts on how I would solve this. But I'm sure there are other ways that might be more performant or easier.

[mbergmann]

Hi,

some thoughts about this:

First, the question is what „exact time“ means in this context - or more precisely: Which level of „exactness“ really makes sense. In the end, the generation and deployment takes some time anyway. And website visitors‘ browsers do caching etc. So usually - at least to my experience, there is some „systematic timing uncertainty“ outside of one’s control anyway and thus a window of let’s say 10 minutes is usually acceptable (or at least doesn’t really matter).

In general, I don’t recommend approaches that do release an object technically but then do some stuff to „mimic a not yet released behavior“ somehow. That approach has too many pitfalls and side effects - so it’s a good idea to concentrate on the timed technical release. 

I‘ve used a workflow approach for such requirements in the past - but not with an active loop and not with „externally stored“ information. Instead, the normal release workflow has a state like „waiting for timed release“. The target time can be stored in the workflows formData / session. This is usually done via an alternative path in the workflow where the user decides between a normal or a timed release. The workflow also contains „the rest“ of bringing the change live when the element leaves the „waiting state“ - like doing the release, triggering the appropriate generation and deployment schedule etc. So the timed release is just an extra „detour“ in the normal release workflow.

So the only „missing“ part is how to advance the element in the Workflow out of the „waiting state“ based on a „timer“.

This can either be done by a artificially/dynamically created extra schedule entry per object (Holger‘s first version) or just by a regularly recurring one. I would (like Holger) recommend the second approach as it’s less complicated and also has less side effects. E.g. it’s much easier to have an extra manual workflow action from the waiting state to CANCEL the timed release because „it’s all in the workflow“.

That schedule entry (regularly run every 10 minutes for example) could use the QueryAgent to find all objects that are in that „waiting“ workflow state, check if the time has been reached and if yes, ONLY advance the workflow (via WirkflowAgent) and the workflow does the rest.

The workflow approach also has some other advantages like being able to „lock“ the object (disallow editing) because usually, the check if everything is ok (e.g. 4 eye principle) has been done before and an element shouldn’t change between that check and the timed release.

Hope this helps 🙂

Michael