Node 2.0 Lessons Learned
From Exchange Network Wiki
Have you implemented Node 2.0 in your organization? Are you in the middle of your upgrade now? If so, share your lessons learned, implementation experiences, or general frustrations on this page. Your bit of knowledge may go a long way toward helping out a fellow Exchange Network partner!
Contents |
Washington
Washington State Department of Ecology announced on October 1st 2008 that it had implemented and is successfully running the Windsor 2008 Node that fully implements all Node 2.0 technology. The 2.0 Version of the node went live on September 24th 2008. A Lessons Learned presentation is currently in the works for the spring 2009 Node Conference in Atlanta.
This latest version, Node 2008, simultaneously supports both the Exchange Network Node Specifications version 1.1 and version 2.0 by providing two parallel endpoints for partner requests, as well as providing further advanced Node management functionality.
The Node 2008 supports the six existing data exchanges previously operated by Ecology (FRS, PNWWQX, PNWWQX Catalog, RCRAInfo, WasteX, and Washington Department of Health Fish Tissue exchange), and will provide two further data exchanges (WQX and AQS) by year end. All of these data exchanges are available through either the 1.1 Node endpoint or the 2.0 Node endpoint.
In addition to these data exchanges Ecology has also implemented a new data exchange exclusively through the 2.0 endpoint. The GeoLocator data exchange extends access to an internal Web service developed by Ecology as part of the Washington State Location Finder application. This Geo-Processing Web Service accepts an input geo-spatial feature (point, line or polygon), and returns a list of spatial intersections between this point and a series of geo-spatial data layers. This new data flow employs the redefined Execute primitive method functionality included in version 2.0 of the Node specifications. We believe that this is the first data exchange to take advantage of the capabilities exclusively provided by the new specifications.
Colorado
In September, 2008, Colorado DPHE upgraded its Exchange Network Node to support the v2.0 specification usin the Windsor 2008 Node. The project included migrating the existing FRS, SDWIS and TRI exchanges to the new node, as well as implementing the WQX and the new Pollution Prevention Results (P2R) exchange. The upgraded node supports existing v1.1 exchanges, allowing CDPHE to continue flowing existing data while ensuring future support for v2.0 exchanges that have yet to be released. The new node also simplifies administration and offers a more flexible architecture for various deployment scenarios. CDPHE is hosting the node on a virtual server which simplified this upgrade and should make future upgrades easier. It also provides much more flexible options for backup and recovery as well as easy portability between servers.
Mississippi
The Mississippi Department of Environmental Quality is currently working on installing the CGI node in a Websphere Application Server 6.1 environment. This section will be updated as we move through the process.
Indiana
The Indiana Department of Environmental Management is currently implementing the Node 2.0 in BizTalk Server 2006 R2. The most recent lesson learned is that when calling EPA the URLs are treated case sensitively. We were able to dynamically call the CDX test instance successfully with the following URL: https://test.epacdxnode.net/cdx-enws20/services/NetworkNode2?wsdl, but failed when we tried to call dynamically using the following url: https://test.epacdxnode.net/cdx-enws20/services/networknode2?wsdl. We were storing the url in our database as all lowercase, and then on subsequent calls retrieving it from the database as all lowercase. This was identified after an extensive research on what's going on with EPA Node 2.0 calls.
GoMOOS OpenNode2 Java Installation and Debugging
Eclipse is our development platform and began by checking out a copy of the OpenNode2 project from google code. Checkout was done directly in eclipse via an Eclipse plugin for SVN.
http://opennode2.googlecode.com/svn/trunk/java
We followed the install instructions, creating the same directory structure for opennode2_home on both production and development (mac laptop).
We're using the same database (node2_prod) for development and production at the moment.
Note: this is for the nodes transaction database not a database which a flow might use.
OpenNode2/Wnos_Service/env/ecos-generic/jdbc.properties
Production system
jdbc.url=jdbc:postgresql://hornet.gomoos.org:5432/node2_prod
Development system
jdbc.url=jdbc:postgresql://localhost:6032/node2_prod
We used the ecos-generic configuration directories. To build the entire project...
Right click on OpenNode2/Resources/ant/build.xml and "Run As" Ant build.
output jar files are located in OpenNode2/Resources/dist/ecos-generic
Debugging
Modify the log4j.properties files (more than one) to enable debug messages in the log file.
webapps/wne2/WEB-INF/classes/log4j.properties
- log4j.appender.LOG.Threshold=INFO
log4j.appender.LOG.Threshold=ALL
Port forwarding ( to avoid asking for opened ports only for development ). This is a way to use a local database client against your remote database.
This forwards traffic from our database server listening on the default port of 5432 to your local machine as port 6032.
ssh webserver.gomoos.org -L 6032:databaseserver.gomoos.org:5432
For example you would start an ssh session with a command similar to the one above and then your local OpenNode2 would use this for a connection string to the database server.
jdbc.url=jdbc:postgresql://localhost:6032/node2_prod
Port 5432 on the database server has been forwarded through ssh to port 6032 on your local machine.
You can use a similar trick to debug with Eclipse. Start Eclipse in the debug mode using JPDA
apache-tomcat/bin/catalina.sh jpda start
Forward the webservers port 8000 ( the default port for the java debugger ) to your local machine (again port 8000.
ssh webserver.gomoos.org -L 8000:webserver.gomoos.org:8000
point at this using Eclipse.
Note: I routinely have to stop and start tomcat (./catalina.sh stop) to make this work a second time.
To sync up the debugger with Eclipse for single stepping through code and adding break point, so far, I've had to checkout the individual parts of OpenNode2 as projects.
So for example to debug the Node 2 Endpoint I would need to set up a project (check out from SVN) for http://opennode2.googlecode.com/svn/trunk/java/Endpoint2, and use that project to set breakpoints and single step through code.
