Unique identifier for a recurring schedule.

[Former Member]

I am creating a recurring schedule for a report and storing the report instance GUID in java application DB. At a later point of time I am trying to get the list of recurring reports from BO . But I observed that the GUID that I've in my database (stored when the schedule was created) does not match with the one in the BO after the recurring schedule has run for a couple of times. Just wanted to check what is the unique identifier for the recurring schedule. From my finding it does not seem to be the GUID /CUID . Please let me know on this.

Thanks.

[ted_ueda · Accepted solution]

Hello Thangamani,

There is no persistent unique identifiers for a recurring instance. You can make your own, by defining a Custom Property for the InfoObject.

I'll explain your observation:

Whenever a recurring scheduled instance is created, a new InfoObject is created and stored in the CMS repository, with a unique SI_ID and SI_CUID values. When it comes time for that recurring instance to be run, the InfoObject is cloned, where the cloned InfoObject is given unique SI_ID and SI_CUID values. The cloned instance is given the recurring schedule's next run time. Then the source InfoObject is put into pending state, to be picked up by a Job Server.

The SI_ID and SI_CUID value thus stays with the generated instance, and gives the appearance that the recurring instance changes its SI_ID and SI_CUID values every time it is run.

This makes it difficult to "track" a recurring instance, for job control purposes.

Any InfoObject, however, can accept a Custom Property. You can create a custom property, and then the cloning described above will copy over the property you set. In this way, you can "track" the instances generated by a recurring instance.

Sincerely,

Ted Ueda

[Former Member · Accepted solution]

Hi Ted,

Thanks for your response. Just wanted to check if it is setKeyword method that you are referring to , to set the custom property . If not , can you please explain as to how custom properties are set and retrieved?

[ted_ueda · Accepted solution]

You can use Keywords for that purpose, but rather, I'm referring to creating your own InfoObject property.

IInfoObject.properties().setProperty("PROPERTY_NAME", "property value");

You then query for the recurring scheduled instances, then iterate each and look for the property value.

You can try hashing name, time, and Thread ID to give the property an unique value.

Sincerely,

Ted Ueda

[Former Member · Accepted solution]

Thanks for your response Ted. I'll try this and will get back.

[Former Member · Accepted solution]

Take heed, though. Custom properties will not be indexed, and querying such CMS objects via one is generally ill-advised. Of course, if you, as Ted suggests, grab all child instances whose parent_id (indexed) is X and have a nice, navigable subset, then sure, you can simply iterate over that collection and inspect the custom property that way.

[fritzfeltus]

SI_CUID and SI_ID are the unique identifiers most commonly used.

It might be more useful to save the recurring object's parent instead (the report template, rather than one of the report's instances). This identifier will not change.