Purging a document via REST API Python script restores older document version

Hi all,

to put this in advance: I’m not sure what category to use here. Yes, it happened when using the REST API via a python script, but the problem seems to be a server admin question…?
I will gladly accept any suggestions…

Here’s the problem:
we found a very strange behavior when purging WebI queries using the REST API via Python scripts (we want to run this regularly in order to follow GDPR regulations).

In some (not all!) cases, a very old (initial?) version of a report was restored.
So, e.g., a report might have been initially saved on 1/5/2023, then it got changed and overwritten several times, maybe saved for the last time on 31/12/2024. But when we ran the script, the version of 1/5/2023 would get restored.
This happened to reports that were up to three years old!

But it did not happen to all reports, and of course, we cannot check several hundred or thousand reports manually whether they were affected or not.

Now this is very puzzling, to put this mildly, for two reasons:

  • Where does this old report version come from??? It is definitely not in the file repository. Is there some kind of cache that stores initial report versions?
  • Even if this version exists (where ever): Why does the Platform restore the old version? There is no reason it should do so!

Even worse: Although we found the effect in several reports, it is nearly not possible to reproduce this actively! We changed an existing report and saved it, then purged it via the script, but this time, the new version remained.

We are completely lost here. Of course, this is a real showstopper as we cannot run a regular process that way.

If the solution is to regularly clear a certain cache before running the script (and that cache directory can be named!) – well not nice, but we could live with that.

Any insights would be much appreciated!

Thanks

Felix

1 Like

There is a Web Intelligence cache location on the servers.

%InstallDir%\SAP BusinessObjects Enterprise XI 4.0\Data%WebIServer%\storage

%WebIServer% will be the server name for the server that hosts your Web Intelligence service. There may also be a folder for each Web Intelligence service that you may have running.

In this storage folder is cache directories for universes and for reports. In the one that I checked in our systems, there were report directories that there up to 8 days old. These directories contained older files so it is hard to tell how long these may be retained without looking through the whole file system.

I would think you could clear this cache periodically if you wanted but I’m not sure what purpose they may server besides speeding up opening those specific reports.

Thanks for the suggestion, maybe that’s the way forward (as in ‘if it’s stupid, but it works, it isn’t stupid…’).
However, it still is very strange:

  • As mentioned, some of the restored documents were more than three years old! Why are they still in the cache???
  • even if so: why do they get restored? The script itself definitely doesn’t do that (the purge simply calls the document by it’s cuid or id, the rest is done by the platform), so it must be one of the platform services.

All in all, it seems very strange to me that we have to manually empty a cache directory before running a script.
If that was the ‘offficial’ way, I think many script writers might regard this as slightly buggy, right…?

@FelixKrul , I didn’t say that it made sense. I’ve just found that Business Objects does weird things for some reason.

The reason I looked at this is because I have seen cases were a universe was migrated into an environment but the environment was still showing the old universe. We had to go to the universe cache at this location and delete the copy of the universe there for the changes to be seen in the new environment. I just extrapolated the universe solution to yours.

Hope it works for you though.

Hello @JohnBClark,
it seems my remarkt about ‘stupid’ may be misleading as an offence against you, and please let me say that this was never my intention. I hope you accept my appologies.

Please let me clarify this:
When I call a WebI document in the WebI appication (or any other object in the respective application), this will open the latest version which is stored in the file repository. A possibly cached document will only be used if it’s of the latest version.
As a summary, the file repository represents the ‘truth’, i.e., the current version of the document.
This is exactly how I would like the REST API call (or a promotion management job or anything else) to behave. If it doesn’t do that, the behaviour is buggy.

So, if you as a developer then search for (and find) a workaround for this, this is definitely not ‘stupid’ (in fact, quite the opposite!), however, the fact that you are forced into finding that workaround is stupid.
And that was what I was referring to.

So, I sincerely hope that no misunderstanding remains.

Best regards

Felix

1 Like

I did not take it as an offence. There are plenty of things with Business Objects that fit this description. I took it as reference to Business Objects, not to me.

You’re all good.