We are experiencing some issues with setting up the Jasper Reporting JDBC connection.
We have a test server (conventional) setup currently running. CA SDM 14.1 is installed on the system and functioning as anticipated on IIS and Tomcat (8080 & 8443).
We installed Tomcat8 for Jasper Reporting that is running on (9090). Apache is installed fine. Jasper Reporting server installed completely without any issue.
We are having issue with establishing the JDBC connection as per the documentation referenced here:
Configure CABI JasperReports® Server r6.2.0 for CA Service Management - CA Service Management - 14.1 - CA Technologies D…
STEP # 3
When attempting to select a JDBC driver it shows com.ddtek.jdbc AND com.ca.casm as being NOT AVAILABLE.
Now if I attempt to follow the instructions as outlined on the documentation above. I receive the following error ...
Full error log has been attached below. It appears that I need to install/obtain the OpenAccess SDK drivers to install them. Is there a link and/or a way to obtain these or point to where they are within the CA SDM installation, I'm assuming.
Any assistance is appreciated!
Is there a firewall blocking traffic on 19987 and 19986 ports ? The error seems indicative of a port closure upon connection attempt.
I am assuming SDM is running on the node that you tried to connect to.
To make things easier in this area we have been performing the installation with the local firewall disabled.
Yes, WTDHSWEBL18 is where CA SDM is installed. Which is also the localhost as Jasper is installed onto the same system for our testing purposes.
Does having those two driver options show as NOT INSTALLED, not make a difference?
I get a response from WTDHSWEBL18 when I ping the device. This is currently the list of listening ports on CA SDM ...
It does not appear that the port is listening (if it makes a difference in this case).
Appreciate any and all further feedback/assistance.
As this is a Windows setup, check if the two SDM ODBC services are running too..
CA Service Desk Manager ODBC Agent (oaagent.exe)
CA Service Desk Manager ODBC Data Access (oasoa.exe/oastrtr.exe)
My previous post had an incorrect port 19986. It should have been 19985.
So, 19987 and 19985 should be in listen mode like this
C:\>netstat -ano|findstr /i 19987
TCP 0.0.0.0:19987 0.0.0.0:0 LISTENING 2448
TCP [::]:19987 [::]:0 LISTENING 2448
C:\>netstat -ano|findstr /i 19985
TCP 0.0.0.0:19985 0.0.0.0:0 LISTENING 4684
TCP [::]:19985 [::]:0 LISTENING 4684
Last column indicates the PID of the program that's listening.
I have also attempted the direct IP address in place of the hostname, as well as localhost, with the same end result ...
When attempting to run netstat on 19987, and 19985 I do not get a return on the query. However, the query returns on port 80 so its safe to say nothing is listening on the ports outlined.
Both of there services are OFFLINE ... When I attempt to start them I get the following errors outlined above.
My thought from here was that the ODBC services need to be reinstalled to restore the functionality. I found the following documentation about fixing these services:
Knowledge Base Articles
However, CMD does not recognize the oa60 commands and I could not proceed.
Try this article - http://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.tec1727288.html
In 14.x, the oa version changed, so its oa72 instead of oa60 as indicated in the above article.
Hope this takes care of it
This is the event log for the service FAILURE above ...
I did found documentation that appears to TO BE CLOSE to this issue (but not exact):
I beat you to the punch, so to speak. But want to post the results so it can potentially help others.
We are running multiple test servers. I noticed I could start the ODBC on WEBL35 (another of our test environments).
I noticed that the service was starting from oaserver60 as you indicated above. I copied the oaserver60 folder and replaced it on WEBL18. Once replaced the services STARTED up without problem.
After it started I attempted the jdbc connection string and it CONNECTED! Ran a test report and got the system to respond.
I duly appreciate your help on this matter and helping me think through the issue.
Glad it helped out.
As this is 14.1 oaserver should be 7.2 version. So the oaserver60 seems a bit concerning.
Is this an upgrade of SDM from 12.x ?
Yes, this is an upgrade from r12.5