Doug Monson

I did a little more testing and came to realize what I think is my issue. I logged into the WebFOCUS application using Chrome but when I clicked on the Excel drilldown link, I never paid attention to the fact it opened up in Edge (which is set as my 'default' browser). Edge doesn't have a session so naturally I was prompted to re-authenticate. From Excel I copied the drilldown link and pasted it into my current Chrome session and the drilldown worked. I then changed my default browser in Windows to use Chrome and the drilldown link from Excel opened successfully in Chrome. I also corrected the drilldown link syntax, but it is important to note that even with the FOCEXEC=app/jwxu52ru.fex syntax, the drilldown works from Excel. This was the original code in the FEX stylesheet - TYPE=DATA, ACROSSCOLUMN=N1, FOCEXEC=app/jwxu52ru.fex(PROGCODE1=N1 ORGNCODE3=N3 ACCTCODE2=A3 ATYPCODE1=A1 COASCODEKEY='1' FSYRCODEKEY='&FSYR_CODE_KEY'), $ I changed the code to - TYPE=DATA, ACROSSCOLUMN=N1, FOCEXEC=IBFS:/WFC/Repository/frsnrc0w/Position_Control/jwxu52ru.fex(PROGCODE1=N1 ORGNCODE3=N3 ACCTCODE2=A3 ATYPCODE1=A1 COASCODEKEY='1' FSYRCODEKEY='&FSYR_CODE_KEY'), $ Thanks for pointing me in the right direction. I'll do some more testing to confirm this is working. -Doug

Hi Patrick, Thanks for the reply. Yes, the URL link in the Excel spreadsheet has the fully qualified address - https://wfdev.customer.com/ibi_apps/WFServlet?IBIF_webapp=/ibi_apps&IBIC_server=WFNT&IBIAPP_app=gold&IBIMR_drill=IBFS,RUNFEX,IBIF_ex,true&IBIF_ex=IBFS:/WFC/jwxu52ru.fex........ So that does make sense that it would attempt to establish a new session from Excel. I also just noticed that the location of the drilldown FEX is incorrect in the drilldown link. The drilldown link is pointing to &IBIF_ex=IBFS:/WFC/jwxu52ru.fex when the actual location for that FEX is IBFS:/WFC/Repository/frsnrc0w/Position_Control/jwxu52ru.fex. -Doug

Good Day, We have a WebFOCUS 9.2.1 environment hosted by ibi in the Cloud. The security for user authentication is provided by SAML (Azure AD). The application uses Excel output in a large number of reports and these reports often contain drilldowns within the Excel spreadsheet. When a user clicks on one of the Excel drilldown links they are prompted to re-authenticate to the SAML provider. I have searched through WebFOCUS configuration settings but have been unable to find anything that changes the behavior. Has anyone seen this behavior and found a solution? Thanks -Doug

Thank you Patrick it works very well. I should have thought to try a Client profile. -Doug

Thanks Mat. I do not have an ON TABLE SET STYLE in the code. I'm trying to avoid putting that code in every FEX and configure WebFOCUS to find the stylesheet globally for each report. Even if the stylesheet was in the Global Resources section, wouldn't each report need to reference it individually with ON TABLE SET STYLE?

I am assisting in a WebFOCUS migration from 7.6 to 8207.28. The 7.6 application uses a single stylesheet to style all their reports. In 7.6, the application has the stylesheet in one of the application directories, e.g. baseapp. The stylesheet is made available globally by the SET STYLE = LANPRT command in the edasprof.prf file. The reference in the edasprof.prf makes the stylesheet available for all reports generated. This same technique does not seem to work in 8207.28. If I put the stylesheet reference in the actual FEX, it will find it and apply the stylesheet -- SET STYLE = LANPRT TABLE FILE CAR SUM DCOST RCOST BY COUNTRY BY CAR END If the SET STYLE = LANPRT is removed from the FEX and put in the edasprof.prf file, WebFOCUS does not find it. I have tried a -RUN after the SET STYLE command in the edasprof.prf file. I also created a FEX with the SET STYLE command in it and tried a -INCLUDE but these techniques did not work. Any suggestions are appreciated. -Doug

Thanks for the reply Patrick. This turned out to be a problem I created. I'm installing WF for a customer with the Dev and QA environments on the same image. I originally installed with a single instance of Tomcat and created the context roots of 'ibi_apps_dev' and 'ibi_apps_qa'. We later decided to install a second instance of Tomcat so we could have each environment use the default context root of 'ibi_apps'. After installing the second instance of Tomcat, I changed the names of the Tomcat xml files in the respective Tomcat instances but I forgot to change the default context root configured in the ibiWebFOCUS92configinstall.cfg file. The following variable declaration in the install.cfg file initially had 'ibi_apps_dev'. When I changed it to 'ibi_apps' and restarted Tomcat, App Studio was able to connect successfully -- IBI_WEBAPP_CONTEXT_DEFAULT=${web:contextPath:-/ibi_apps} Lesson learned. Thanks for reaching out. -Doug

I'm having and issue with App Studio 9.2.1 connecting to our WebFOCUS 9.2.1 environment. After providing credentials to login, I see a message stating - "Warning: potential problem working with localhost. The environment being connected to does not have updated files required for proper functioning of the HTML Canvas. Please contact your WebFOCUS administrator for more information regarding this warning" I never get logged into App Studio. Has anyone experienced this? Any resolution? Thanks, -Doug

Kartik, Are you asking if WebFOCUS 8204 can access the latest version of SQL Server as a data source or use it as the WebFOCUS repository? As a general rule, older versions of WebFOCUS can access newer versions of SQL Server but may not be able to take advantage of the latest enhancements to the newer version of SQL Server. This is because older versions of WebFOCUS also use an older communication layer that may not be able to understand any new enhancements to SQL Server. In 8204, SQL Server 2016, 2014, 2012, and 2008 are supported for the WebFOCUS repository. SQL Server 2017 and 2019 might work but if you have any issues you may not get support since I don't believe 8204 was tested using those versions. Also for a SQL Server repository, the database collation must be case sensitive (CS). -Doug

Hi Merin, The first version to support Windows 2022 is 9.1.1. -Doug

Garth, another possibility is to use a personal access token (PAT) in place of the password in the GitHub connection parameters. The PAT is very easy to generate within your GitHub account. Copy the PAT value and use it as the password string. When you use the PAT the GitHub repository can remain Private without issue.

I was able to answer my own question. It seems that the GitHub repository must Public in order for WebFOCUS to successfully connect to the repository. I created my repository as Private but once I changed it to Public, I was able to get past the bad credentials message. If anyone is aware of a way to use a Private GitHub repository, I'd be interested in knowing how that is done. Thanks, -Doug

I am configuring WebFOCUS 9.1.0 to use a GitHub repository for source control management. I have created the GitHub repository and have successfully logged into GitHub via a web browser. I've been using the WebFOCUS doc and this YouTube video as reference - https://www.youtube.com/watch?v=r6lw74LhFLE. I have enabled Source Control Management in the Administration Console. When I try to place a WebFOCUS Workspace under the control of Source Management, I receive the following error message -- Generic SCM exception: -FETCH- SCM_COMMAND_BAD_CREDENTIALS: Bad credentials Any guidance is appreciated, thanks. -Doug WebFOCUS 9.1.0 Windows (on-prem)