As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
We have two repositories in two different data centers and we also run the Distribution server one in each data center pointing to that corresponding repository.
Now we face a problem where we end up with a requirement of having the requests submitted in one Reportcaster should also be replicated in the other datacenter and viceversa.
please let me know whether has anyone come across a similar situation and the approach you take to resolve the problem.
You didn't say what release you are running so please update your profile's signature with release and platform information.
If you have release 7.6 (not sure if this is available in a previous release), check the WebFOCUS and Report Caster Installation and Configuration Manual. In Chapter 9, page 217 of my Unix version, there is a section on Change Management Migration Steps if you only want to migrate (in your case copy) selected schedules.
Anyway, check the install guide. If you don't have one inhouse, download it from the website. I just checked my copy and the change management stuff is in there.
My firm has a similar setup. (Nearly) matching RCaster installations in North America, Europe, and Australia. Each has their own repository and set of schedules, many of which are (nearly) alike.
GinnyJakes's suggestion is worth persueing, but I suspect it is designed to bring ALL the schedues into the new repository. If you want to bring only SOME to the new location, then in my experience, the only thing to do is manually recreate the new 'copy' schedule.
Bring up the source RCaster schedule's tabbed dialog in a browser window. Bring up the new schedule's tabbed dialogue in another broswer window. Copy-n-paste from one to the other. Sounds tedious, but a schedule can be copied in this way in under 2 minutes.
I don't understand why you'd want the exact same job and schedule running in two places, unless one is a disaster recovery machine for the other. I would suspect that while the schedules may be largely alike, they will differ in distribution e-mail @s, FTP sites, Address book lists, task parameters, etc.
Don't foget that you have to move the execution FEX, too, and that means constructing similar/paralled MRE domains and Apps libraries. These are easiest done by mapping the IBI directory of both servers to your local workstation, then opening them in two windows and dragging-n-dropping the apps files. For MRE, open 2 MRE browser sessons and do SelectAll and Copy in the open source fex, followed by Paste in a new destination MRE source-edit window.
Chris Burtt
WIN/2K running WF 7.6.4 Development via DevStudio 7.6.4, MRE, TextEditor. Data is Oracle, MS-SQL.
Posts: 154 | Location: NY | Registered: October 27, 2005
Using sql server transactional replication with horizontal filtering should solve this issue. you can ask your db to setup : 1/ Create a publication on SERVER A containning the repository you want to replicate. This should be a transactional replication. 2/ Specify the tables you want to replicate and publish them. 3/Make the SERVER B homing the other repository as a subscriber to the publication created in setp 1
Note : a/ Each time a line is created on server A it will be immeditaelly transfered to server B b/ If there are schedules maintained locally on server B then you can instruct the server not to delete them
Some of the Terms I am using here should confuse use but if you talk to your DBA he will understand.
Regards.
WebFocus 7.6.5 AND WebLogic server as web server sql2005 as database server
Posts: 273 | Location: Europe | Registered: May 31, 2007
As we are handling the schedules from the Java application using the ReportCaster API, i dont think we can manually go about with the copy paste mechanism.
Anyway we are now planning to go with the DB replication as Majid mentioned for now. but that is not finalized yet.
Let me also go through the release note before making the concrete decision.
The doc I referred to is in the installation guide, not the release notes. And if you don't want to be selective about the schedules, you can run rcextract and take everything.
But Majid's technique is real time; the one I am referring to is not.