In large integration environments, simulators can drastically improve the testing process. Constructing simulators, however, is another development task that takes up precious time and resources. Using a dynamic language like Groovy, conversely, can facilitate the quick creation of working simulators in a matter of hours.

For example, imagine a B2B environment where various partners communicate in a hub and spoke model. A partner sends an XML document, which eventually reaches a receiving party, who in turn responds with an acknowledgement. System testing in this architecture is challenging at best; however, if the interfaces between partners has been established (think XML documents), then stubbing out various partners becomes a simple task of creating a simulator to accept XML and respond with the corresponding acknowledgement.

Groovlets are essentially servlets written in Groovy; however, they are much much easier to construct. There is no need to extend a base class- just create a simple script and drop it into a configured container and things works like magic. Groovlet’s have implicit access to the Request and Response objects, in addition to a few other common Servlet specification objects as well. What’s also impressive about utilizing Groovy in this situation is how incredibly easy it is to do mundane things, such as parsing XML, manipulating web requests and responses, and rapidly deploying modifications.

Parsing an incoming XML request is a matter of employing Groovy’s XmlSlurper utility, which facilities accessing data in an XML document via GPath (think XPath).

The following incoming XML needs its SesssionID pulled out and applied to a response document:

<?xml version="1.0" encoding="UTF-8"?>
<ziIOW xmlns:ds="http://www.acme.org/8303...">
 <ziHeader Version="1.4">
   <Service Version="1.4" Name="BILL_PAY">
    <TimeStamp>2001-12-17T09:30:47.0Z</TimeStamp>
    <UUID>8983933-OIO-893111</UUID>
   </Service>
   <Request>
    <VendorID>905RTE3</VendorID>
    <BizID>E32R</BizID>
    <SessionID>MV_8934_KER</SessionID>
   </Request>
 </ziHeader>
 ....
 ....
 </ziIOW>

Grabbing the XML from the incoming HttpServletRequest and obtaining the SessionID couldn’t be any easier:

def xml = request.getReader().getText()

def doc = new XmlSlurper().parseText(xml.trim())
def sessionid = doc.ziHeader.Request.SessionID.text()

Note how in Groovy, a normal Java IO Reader object has a new method on it: getText(). This makes IO incredibly simple!

Next, a canned response is generated, which requires a unique UUID and the same SessionID of the request. As this is a simulator, the rest of the XML response, which would undoubtedly be important in a live environment, is static.

Generating a unique id is straightforward via Java’s Random class and a healthy usage of Groovy’s String substitution ability (aka GStrings):

def rndm = new Random(new Date().getTime())
def ruuid = "sim_grv_${Math.abs(rndm.nextLong())}"

Obtaining the canned response also utilizes Groovy’s GStrings via the ${value} syntax:

def getXMLResponse(uuid, sess_id){
  return """<?xml version="1.0" encoding="UTF-8"?>
   <ziIOW xmlns:ds="http://www.acme.org/8303...">
     <ziHeader Version="1.4">
      <Service Version="1.4" Name="BILL_PAY_RESPONSE">
       <TimeStamp>2001-12-17T09:30:47.0Z</TimeStamp>
       <UUID>${uuid}</UUID>
      </Service>
      <Request>
        <VendorID>905RTE3</VendorID>
        <BizID>E32R</BizID>
        <SessionID>${sess_id}</SessionID>
      </Request>
     </ziHeader>
     ...
     ...
     """
}

Note, the meat of the XML isn’t shown as its static; hence the … in the code above. Also note the usage of Groovy’s """ synatx for multi-line Strings. Via the """ synatx, escaping isn’t required, which helps in using XML in Strings.

Finally, the XML response is sent back to the sender:

def xmlres =  getXMLResponse(ruuid, sessionid)

def responseout = response.getOutputStream()
responseout.print(xmlres)

Because this Groovlet is a simple script living in a web context, if modifications are necessary, it’s quite easy to change things locally and redeploy the script, not the entire war file.

The hardest part in building a B2B simulator in Groovy is determining the interfaces involved (i.e. the incoming request XML and outgoing response XML) and what pieces of data must change. Once those are understood, coding a working B2B simulator in Groovy takes minutes!