JCAPS Unit Testing - Part 1
Since starting with JCAPS last November, I've looked for a better, automated way to test my code. During JCAPS training, the test exercises are kicked off by placing files into a "hot folder" monitored by a File eWay. It's very cumbersome to monitor the directory after placing the file - constantly refreshing the window, wondering why the file is not being picked up - or what is taking so long. In my company's environment, the JCAPS development server ran on a shared machine that was cumbersome to access - adding to the difficulty in dropping this file. Since most of our components listened on JMS queues or topics, dropping messages directly to these queues would've been an option, but these were not accessible outside the machine.
I knew there had to be a simpler, more elegant way to trigger our tests. What I needed was a way to drop a JMS message into the system and trigger my JCD. What I wanted was a servlet-like mechanism that I could trigger at will from a web browser to drop the test message into the system, then get the resulting message and return it to the browser.
I started to experiment with the HTTP Server eWay. One of the properties of the HTTP Server External Configuration (from the Connectivity Map) was servlet-url. The plan was connect to this URL to trigger the test. On paper it sounds great, but there are some tricks.
First, you need to know which port on the JCAPS Integration Server accepts HTTP requests. By default, the generic HTTP port is one more than the Integration Server Admin port (or +4 for the HTTPS port). For example, if the Integration Admin port is 18000, the HTTP listener typically runs on port 18001 (18004 for HTTPS). You can verify these values on your systems using the JCAPS Domain Manager.
Second, reaching the servlet is not as simple as typing http://localhost:18001/servlet-url. For some reason JCAPS also requires the deployment profile name, the string "_servlet_", and the servlet-url twice (sperated by a "/"). The URL should look something like this, http://localhost:18001/deploymentName_servlet_servlet-url/servlet-url. It took me a while to discover this, but once I did it works like a charm.
That's it! Now you can execute a JCAPS JCD from the browser. Using input.getResponse().setText() and input.sendResponse() you can send information back to the user.
Next, I'll describe how I integrated this approach with JUnit to remotely unit test my deployed JCAPS modules.
I knew there had to be a simpler, more elegant way to trigger our tests. What I needed was a way to drop a JMS message into the system and trigger my JCD. What I wanted was a servlet-like mechanism that I could trigger at will from a web browser to drop the test message into the system, then get the resulting message and return it to the browser.
I started to experiment with the HTTP Server eWay. One of the properties of the HTTP Server External Configuration (from the Connectivity Map) was servlet-url. The plan was connect to this URL to trigger the test. On paper it sounds great, but there are some tricks.
First, you need to know which port on the JCAPS Integration Server accepts HTTP requests. By default, the generic HTTP port is one more than the Integration Server Admin port (or +4 for the HTTPS port). For example, if the Integration Admin port is 18000, the HTTP listener typically runs on port 18001 (18004 for HTTPS). You can verify these values on your systems using the JCAPS Domain Manager.
Second, reaching the servlet is not as simple as typing http://localhost:18001/servlet-url. For some reason JCAPS also requires the deployment profile name, the string "_servlet_", and the servlet-url twice (sperated by a "/"). The URL should look something like this, http://localhost:18001/deploymentName_servlet_servlet-url/servlet-url. It took me a while to discover this, but once I did it works like a charm.
That's it! Now you can execute a JCAPS JCD from the browser. Using input.getResponse().setText() and input.sendResponse() you can send information back to the user.
Next, I'll describe how I integrated this approach with JUnit to remotely unit test my deployed JCAPS modules.
Comments