Cognos Analytics

 View Only
  • 1.  Jupyter Notebook for Cognos Kernel Not Connected

    Posted Thu February 15, 2024 04:02 PM

    Hello,

    I have installed and configured Jupyter Notebooks for Cognos and as far as I can tell everything is configured correctly. I am getting "YOu are Connected to Cognos Analytics for Jupyter Notebook!" when browsing port 8000 of my Jupyter server, and the config files and FQDNs are all set. Cognos environment is set, but when creating a new notebook I get a Not Connected status of the Kernel.

    Jupyter Kernel not connected
    How can I track down whats going on here?


    ------------------------------
    Jackson Eyton
    ------------------------------


  • 2.  RE: Jupyter Notebook for Cognos Kernel Not Connected

    Posted Fri February 16, 2024 08:25 AM

    Hi Jackson,

    Tell me what version of Cognos you have and what OS you run Jupyter on and with Docker or Podman.
    http or https? With or without a gateway?
    Have you configured Jupyter service location in System\Environment?



    ------------------------------
    Jerzy Konarski
    ------------------------------



  • 3.  RE: Jupyter Notebook for Cognos Kernel Not Connected
    Best Answer

    Posted Fri February 23, 2024 10:36 AM

    Hi Jerzy,

    I did get my issue with this resolved. I will confirm a few details for others here:
    Jupyter for Cognos is installed on RHEL, Cognos is on a single server (easy install), everything is http. I found that the jupyter server has to be reachable from the point of browser origin... Meaning on my intranet I had cognos configured to point to my jupyter server and port forwarding setup to reach my cognos server externally as well. Cognos and Jupyter worked internally no problem, but externally it would not connect the kernel. I had to setup DNS and reinstall everything such that internal and external FQDN addressing were the same. This way I could set the Jupyter server address in the Cognos configuration to a server that is reachable both internally and externally. It would be nice if Cognos brokered that communication directly to the Jupyter server, but as it is, the browser is what references the jupyter address from the config, and if it can't reach it, the kernel won't connect.



    ------------------------------
    Jackson Eyton
    ------------------------------



  • 4.  RE: Jupyter Notebook for Cognos Kernel Not Connected

    Posted Fri March 01, 2024 09:00 PM

    Great to hear you were able to find a resolution! Thank you for sharing! 



    ------------------------------
    Austin Rexroat IBM Community Manager | AIOps | Integration
    ------------------------------



  • 5.  RE: Jupyter Notebook for Cognos Kernel Not Connected

    Posted Mon March 04, 2024 09:05 AM

    Hi Jackson,
    My setup is a little different.

    I have one CA instance with Content Manager and Dispatcher and another with the gateway. 
    Jupiter container runs with Podman on RHEL 9. All in http for the moment.
    It works well when I connect to CA directly through the dispatcher (9300). When  try to go through the gateway the Jupyter server is no longer available :(.



    ------------------------------
    Jerzy Konarski
    ------------------------------



  • 6.  RE: Jupyter Notebook for Cognos Kernel Not Connected

    Posted Tue March 05, 2024 08:39 AM
    Edited by Jackson Eyton Tue March 05, 2024 08:47 AM

    Hi Jerzy,

    That kind of makes sense to me, the Jupyter configuration file needs to be set to point to the dispatcher server. The Gateway server FQDN is not in the config file I presume, and I dont think that it should be. However, if its not then I think it may be possible that the jupyter server is refusing the connection as the gateway FQDN is not in the config file? Based on what I experienced the Jupyter server has to be reachable from the machine that you are using to access cognos, meaning your workstation. I think this is a design flaw.

    # COGNOS_HOST is an optional parameter to point the Jupyter server to the Cognos Analytics host.
    # By default, the Jupyter server uses the "Dispatcher URI for External Applications" environment parameter
    # from Cognos Configuration, however if needed, it can be overwritten here.
    # Examples: https://cognos.domain.com:9300, http://9.23.132.233:9300, http://another-cognos-host.com
    # NOTE: "localhost", or "127.0.0.1" cannot be used.
    COGNOS_HOST=

    I need to do more configuration testing, I'll see if I can get a distributed install working (thats how we run in production too), and get Jupyter configured for it. Could you try adding both Dispatcher and Gateway URIs to the config file, comma delimited as shown in the Examples line?


    To expand on the behavior that I was able to test. Lets assume I have one cognos server and one jupyter server. The Jupyter server does not have an externally reachable FQDN, but it is on the same subnet as the dispatcher and the dispatcher can reach it locally via the internal FQDN. Using any machine that can also reach the private FQDN of the jupyter server to access cognos will work. However, if you have the dispatcher configured for external/public access, any machine using cognos publicly cannot access the jupyter server directly and therefore the kernel will fail to connect. To me this is a design flaw and the connection between dispatcher and jupyter should be direct between the servers, not based on the users originating network location. This could be a requirement of jupyter notebooks that I simply don't understand though.

    ------------------------------
    Jackson Eyton
    ------------------------------



  • 7.  RE: Jupyter Notebook for Cognos Kernel Not Connected

    Posted Wed March 06, 2024 06:13 AM

    On the Jupyter side I clearly indicate my CA machine.
    On the CA side I use IIS. In the "CA_IIS_Config" script there is a parameter for the jupyter host - jupyter_host_spec - and I used it.
    Everything seems well configured, the redirects are there, but it doesn't work. It's strange.
    I have had a case at IBM open for 3 months, but still no solution.



    ------------------------------
    Jerzy Konarski
    ------------------------------