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.
Run migrspecific.bat while logged onto target system box and alter rcmigrate.properties to point at the source system.
I would suggest loading schedules one at a time and being very careful.
If you INSERT it tries to insert new keys always and the last action where it tries to insert the report caster user usually fails.
To replace you will need the same ids etc.
The screen looks nothing like that in the docs which is prob why it has been deleted from the distribution CD.This message has been edited. Last edited by: hammo1j,
Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2 Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo
Posts: 888 | Location: Airstrip One | Registered: October 06, 2006
Joking aside, thanks for the support and it is sometimes quite theraputic to post solutions as you are looking!
Also found out "test to live" is "change management" in wf terms and there are facilities for.
1. Dashboard 2. MRE 3. Reportcaster 4. Deploy an Application in DS
Anyone with experience of these? or do you tend to do manual copying which I have been doing till now.This message has been edited. Last edited by: hammo1j,
Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2 Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo
Posts: 888 | Location: Airstrip One | Registered: October 06, 2006
I have used the Change process to migrate MRE components and it does work well - once you have got it setup properly. The advantage used to be that the domain, group and components retained the same names that were sometimes "invented" when the number of characters in the name exceeded of didn't match the limits for each item (domain, group and component). So that when your fex called "Nice_new_report_on_Car_file" was put into MRE and it conflicted with an existing report name called "Nice_new_report_on_GGSales_file" and was therefore renamed to something like "xh34btys.fex", it actually remained that name when migrated to Prod from Dev.
Now, of course, there isn't the same problem as the eight char fixed length on MRE components has been removed (since 7?) and the actual domain and group names seem to function OK.
You know what I am going to say though and that is that I still, mostly, prefer to do it manually as it keeps the mind fresh on how it all hangs together
T
In FOCUS since 1986
WebFOCUS Server 8.2.01M, thru 8.2.07 on Windows Svr 2008 R2
WebFOCUS App Studio 8.2.06 standalone on Windows 10
Posts: 5694 | Location: United Kingdom | Registered: April 08, 2004
Question about using this technique to move Schedules ...
Doesn't the underlying FocExec library structure (MRE/Domain/StdRpt/Group/*.fex or apps/appdir/*.fex) have to be exactly the same in both environments, and populated with the same path and *.fex names?
I can't imagine the migration tool could change the path to or name of the execution code used by a schedule's task as it copies the Task entry from one repository to another. By what process would it search the target database for as 'equivalent' executable if it found the path there was different from the one named in schedule's Task data?
It seems the migrator is fine for dev->prod moves when you've got two separate WF environments, but the two-window copy-n-paste method is still the only way if you've got but one (shared) environment wherein User/OwnerID separates dev from prod.
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
You're right - even pointing a reportcaster at itself to move jobs retains the userid.
Unfortunately you cannot clone between userids so it is going to be 2 screen copy unless you go the whole hog and write an application to do what you want in TABLE and MODIFY. We got something that does similar in our MRE to copy domains and users etc etc so it is not impossible.
Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2 Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo
Posts: 888 | Location: Airstrip One | Registered: October 06, 2006
We have just upgraded to 7.65 and have two environments, dev/test and production. We are implementing change management. I was wondering if you could share any policies and procedures you may have in regard to change management.
I want to make sure we are inline with what others are doing in terms of policy. Some of the concerns that have been brought up are turn around time, who should be allowed to move reports, and report castor.
Any help is greatly appreciated. Prefer if you could share a change management policy and procedure document.