Endevor "shapshot" at certain date

[Giovanni Creato]

Dear Endevor Community,

Today I run into this customer query:

How to extract a snapshot of Endevor Elements at a certain date? For example, extracting the code residing in a certain inventory location as it was the fist Monday last month.

As we all know, Endevor tracks changes using Element versions and by default you retrieve from Endevor by version number (and not by date).

Looking forward to hearing your ideas!
Regards

[Jose Benigno Gonzalez]

As far as I know, we don't have an out-of the-box solution for this request, but a program could be created that calls the Endevor API and retrieves the date and time of the last Element level for the specified inventory location. In a second step, the data obtained from the Endevor API call could be filtered based on the required date and time criteria.

Perhaps, you could also use a restAPI call to Endevor web services from a rest Client but you would also need to preprocess the data obtained based on the selection criteria.

I hope this can help you move forward with the client's request. 

[Joseph Walther]

Under the right circumstances, and with a little planning, the LIST ELEMENT action can give you a workable snapshot of inventory at a point in time. This action provides the version and level values for every element. As long as the inventory remains in the snapshot location—meaning it is neither MOVEd nor DELETEd—this LIST Element snapshot can serve as the basis for subsequent inventory actions.

It is possible to retroactively create a LIST ELEMENT snapshot even without prior planning. However, the success of this retroactive snapshot creation depends on the date and time values assigned to each version and level number, as these represent the date and time of the change. Since the Summary of Levels CSV data does not include timestamps for "Generates" and "MOVEs," the retroactive process has some additional limitations:

• It might identify the level for an element after it was changed but before a successful "Generate" action.

• The change date and time might reflect a modification made in a previous environment, occurring before the element was "MOVE"d into the snapshot's target location.

If these considerations are acceptable for your next step, refer to the "Retroactive Snapshot process" on GitHub.

[John Scott]

I would first ask them more questions about the scenario that they have in mind and the general issue they want to solve.

Is this something to be automated or a one-off ?

One solution may be overkill whilst another is too flaky. Depends on finding out the customer's real requirement.

They may be aware that Endevor does not keep the source that was deleted as part of normal processing when an element is moved or transferred from on inventory location to another depending on the Endevor set up and how its used.

So if you were relying on source management keeping it as was on a particular date for an inventory location you would often be disappointed.

However the source history may be available for an associated element with (same name in a different inventory location) but then it would depend on it having being moved or transferred "with history" which is not a typical practice so unlikely to give you a solution.

I would find out more about the requirement, do they see this being required for all inventory locations or maybe just at pre-prod or prod or whatever.

To go back to source at a particular element at an environment system subsystem stage type that existed at a random date and time in the past you would need to have saved the contents externally at the time because Endevor is not designed to save history like that.

The solution depends on whether this required for one-off purpose or part of a standard process?

Endevor unload housekeeping might give you something but that may only run once a night and not contain granularity that you want for an element that only existed for an hour in the afternoon.

If you know you are likely to want the contents of an inventory location back in future the ARCHIVE action will capture all the source that you can use to RESTORE from. But did you want the executable that existed at the time too ?

The archive requirement may be different at test from pre-prod - do you really need to save every single change made when getting program to compile first time ?

You could schedule this ARCHIVE or build it into an automated process as part of moving elements but it would be an overhead you would need to weigh up the benefit versus likely hood of being used.

Another option is Bridge for Git where you set up one-way mapping from the Endevor inventory location into a github repo set up for this purpose. So you might send everything that got promoted to a certain stage to that repo and keep it.

Other than that there are non Endevor backups of MCF BASE / DELTA source outputs but you would need to restore these on a different recovery system just for the purpose of recovering the inventory location source - maybe using ARCHIVE to take it to sequential file for restore on the live system.

This would be a massive overhead, cause confusion in Endevor and be unlikely to be worth the effort.

So I would try and get more info about what they are really wanting to achieve first.