I’ve been playing around with the Repository Diagnostic Tool, but haven’t had much joy with it. The documentation is rather anemic, so I’m struggling to figure it out on my own. I created a seperate text file with the options that I want. I hope I set that up correctly. It looks like this:
This has nothing to do with the CMC. The Repository Diagnostic Tool (RDT) is a new component in XI 3.0, with similar functionality to the old Scan/Repair/Compact in 5.x and 6.x.
I finally got it working this morning. There are some errors in the documentation (surprise, surprise ).
The command line parameter -options- should be -optionfile (Page 9) -outputdir is a mandatory argument, not optional. If left out, the tool tries to write to a nonexistant folder. (Page 10) Make sure that all referrences to directory trees are in double quotes.
Thanks… for sharing. It would be even better if you put the exact code that you are using(except user/pass) for your text file and the command prompt syntax in this thread.
We also got this tool to work. And it created a rather ugly xml logfile.
The documentation (and BO support) said I should be able to view this file as a pretty html file by using the rdt-scan and rdt-repair style sheets. This did not work because the style sheets were provided in an unexpected directory.
Our “fix” was to move the tool and associated resources from D:\Program File\Business Objects\BusinessObjects Enterprise12.0\reposcan to D:\Program File\Business Objects\reposcan. It works very nicely now.
By the way, we’ve had a support case open on this issue for over a week. Although we had several conversations with BO support, no solution was offered.
The short answer is Yes. The long answer is be very very careful, or take precautions. After running reposcan I had the unfortunate situation where I couldn’t access the CMS. I couldn’t log in, I couldn’t run CCM although it opened and appeared as all services where running.
I did the next correct step and contacted SAP support. While waiting for a reply, I serched for any files that had been changed which had the same timestamp as the output file from reposcan. Lo and behold, the file;
\Business Objects\BusinessObjects Enterprise 12.0\win32_x86_boe_.dbinfo was changed.
Apparently I had made an error in the database parameters in the options file, and the support desk informed me later that if I get that wrong, and reposcan cannot find the repository, it deletes the repository conection information, which is in this file. So my definite advice is to back this file up, actually backing up the entire install directory is advisable for future reference before doing ANYTHING in the FRS or CMS.
I hav attached a copy of my 2 files I use; the options file and a batch file to run the whole thing. Note some things have been changed for security reasons.
You will notice I have moved my input and output files from the default, this was only to make backup easy and has nothing to do with reposcan. Just edit the values to match your installation.
Good luck; BusinessObjects is 2 parts codeing, 2 parts workarounds and 1 part luck. reposcan_check_options_noID.txt (0.0 KB) runRepoScan_noID.txt (0.0 KB)
Hi davidmo - much appreciated - it’s not often that posts contain such a complete explanation along with all the details
So did your repo scan physically create a CMS entry from and FRS entry?
The scripts you posted were very similar to the ones that I ran - and I don’t have an issue with connectivity as the repo scan does run and identifies all the missing entries - it just won’t repair them lol
File C:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\FileStore\Input\a_000\017\000\4352~ce20dc5498d4538c3.wid exists in the Input or Output FRS, but there is no corresponding InfoObject in the repository. Please republish the file. The application will not publish this file for you
So I’ve been trying the option of creating a shell webi report and then physically copying these entries into the shell just so as to use the idenifier in the repository. I’m getting some weired results with this. but will persevere until my patience runs out.
I just can’t see why it’s such an issue for the reposcan to not be able to regenerate the repo details - I basically have a 10 day gap between CMS entries and the FRS.
Thanks
I think that writting an application to fix the missing links would pose a few problems. I opened each file directly from the Filestore and found that they all were duplicates so I just deleted them and the next run deleted the empty directory. If there were any (wich there weren’t) that were not duplicated, then I would have saved them somewhere with the correct name, deleted the one in the Filestore, ran reposcan to delete the empty folder then republish.
I feel that efforts to write a better reposcan would be better putting into fixing what causes the problem. A bit like shutting the gate BEFORE the horse gets out.
Maybe a safer reposcan, maybe not a command line program would be OK and that should be a lot less development. Maybe an opportunity for a 3rd party tool, maybe I should shut up and write it myself LOL.
- yeah, the tools never quite do what we want them to do.
I can kick myself as I finally cottoned on to the fact that I have these *.wid documents in the File Store without CMS entries, but that I have Web Intelligent Rich Client to open them with, and then repost them into the CMS. You just have to rename them away from that 'orrible unreadable data string name, and some have a few strange lost data providers, but something is better than nothing.
And Yeah - a few scripts would come in handy - and it surely cannot be that difficult to regenerate CMS entries. I think the issue lies in trying to decipher the encrypted data in the actual document.
A scheduled BIAR and File Store backup script would also be handy lol
… let me know how it goes if you ever get some idle time and the scripting itch
Well, to be confirmed, but I just witnessed a strange (and quite dangerous) behavior…
From the RDT admin guide, the -repair option set to “false” explicitly denies the application to repair inconsistencies… well, it sure did all repairs to my CMS !
It seems that one has to NOT use this option at all to avoid repairing…
It did not broke anything and I was doing it on test environment, but still :?
when setting up output dir varialbes… I pointed output dir to
C:\Filestore\Input
This has been in place - for a couple of months
my plan to correct
copy The entire content of C:\filestore\input to C:\filestore\output
Then correct output vaiable
Then use repository diagnostic tool to correct and cleanup
When I ran the RDT it says it completed ok, but my concern is that it did not clean up enough… I say this because it only repaird a couple hundred of items, and the disk size is basically the same size it was before.
the orig file store was 200 gig. I copied that to output – my “new” filestore is now 400 gig… I was expecting the filestore to shrink back to 200 gig.
I have opened a case with support… They feel this maybe a bug ???
For what it’s worth, the following commands worked for me. I have not yet tested a repair, but the syntax may help someone get going with an Oracle CMS database.
If you notice the print out from just running reposcan.exe, it will say the connect parameter for Oracle is “oracledatabasesubsytem”. This is incorrect. It should be oracledatabasesubsystem.
Also, as someone said above, the outputdir is mandatory (though the user guide says optional).
Underscores are fine in the Oracle username and password provided the connect parameter is in quotes.
One last note, none of the directory specifications can end with a slash…
Thanks to everyone for so much info on this topic. I found the documentation in the manual titled “T-BOEXIV3-4251_Administrative_Tools_and_Tasks_Activity_Guide.pdf”