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 a portal that has a set of filters (placed in left banner) that updates everything on the portal.
**The thing about our portal filters are that they are passed to a hidden (pushed below view) captureSelections.fex at the same time as all the other content when the submit button is pressed that captures the user selections, storing them in a hold file specific to the &IBIMR_user logged in at the current time, to be used in an additional generateParms.fex that is included in all the content in the other panels that can use the params generated to display the content correctly. (This generateParms.fex creating new amper vars from both requests from the user hold file and the screened data source.)
The filtering process goes as follows:
- filter.html with controls populated by external procs that request field data with a screening filter applied (for user specific data).
- captureSelections.fex that stores selections in virtual define fields to be then requested and stored in a user-specific hold file.
(above is requested from within...)
- generateParms.fex that takes the field values from the user-specific hold file and additional field values from the data source being screened against and stores them in new amper vars that are then usable in the content this .fex is included in at the top.
(above included in)
- content displaying on portal in panels.
The issue we are having is that when the user hits the form submit button, it takes 2 submissions before everything updates properly.
I was thinking I could use the BipIframeInterface.REFRESH_ARRAY BIP refresh option to only update the captureSelections.fex first, then use the other REFRESH_ALL_BUT_SELF option after that in my refreshReports() function. Is this a possible solution you think?
Current refreshReports():
function refreshReports(){
var name = this.window.name;
parent.BipIframeInterface.setAllAmpersValues(name, IbComposer_getAllAmpersValues());
// Insert REFRESH_ARRAY option call here?? Do I need a timer??
parent.BipIframeInterface.refresh(parent.BipIframeInterface.REFRESH_ALL_BUT_SELF, name);
}
If this could work, what is the syntax of the REFRESH_ARRAY option? It is not documented in the online documentation.
Any help would be appreciated! Thanks in advance!This message has been edited. Last edited by: CoolGuy,
8.2.02M (production), 8.2.02M (test), Windows 10, all outputs.
Posts: 1113 | Location: USA | Registered: January 27, 2015
Thanks so much for the link to how it can be implemented. Appreciate it.
I tried setting up my refresh function as follows...
function refreshReports(){
var name = this.window.name;
// Below iframe panel is for the captureSelections.fex so we can run it and let it finish b4 refreshing other panels.
var iframeArray = ["Panel_2_1"];
parent.BipIframeInterface.setAllAmpersValues(name, IbComposer_getAllAmpersValues());
parent.BipIframeInterface.refresh(parent.BipIframeInterface.REFRESH_ARRAY, name, iframeArray);
setTimeout(parent.BipIframeInterface.refresh(parent.BipIframeInterface.REFRESH_ALL_BUT_SELF, name), 5000);
}
...and then reinserting the form into the banner before trying it, and it still fails to update without having to submit twice.
Ugh.... This app was set up this way when I got hired on. My thoughts are that I will be looking into modifying the app by totally getting rid of the user-specific hold file (that serves no purpose that I can see code-wise) and replacing it with a "Save Selection" button next to the Submit button letting users save their portal state and run it later. As for the generateParms.fex and content, I will make sure the screening filter is in place and any needed extra ampers are available for the specific content populating. The screened datasource will eventually be replaced with a SQL table/view instead of the .foc mart that it is currently.
The data is being pulled from actual SQL tables with data descriptions and being held in a hold file until eventually being matched and merged into the .foc mart in a huge load.fex that is basically an ETL. Hoping to just get a clean SQL version here soon. That might help processing tremendously. lol
Anyone else think there is a workaround for me having to submit twice before data updates across the portal until we can clean this app up??
Thank you all for your help and understanding!
8.2.02M (production), 8.2.02M (test), Windows 10, all outputs.
Posts: 1113 | Location: USA | Registered: January 27, 2015