Wednesday, May 25, 2011

Using the SoapUI mockupserver in a OSB / SOA environment.

http://groovy.codehaus.org/When developing applications you always need to connect to others systems. Those systems are not always available or not in place at the right time. A mock-up server, also known as stub server, is a good temporary solution. In the product stack of SoapUI a very good mock-up server is available. Apart of a nice GUI interface to develop the mock services, scripting based on Groovy, it is free of license:-)

Info on SoapUI Mockup server:
In your development environment you should place the mock-up server along your OSB and/or SOA development server. Deploy your mock-up services to the mock-up server. Now make sure your endpoints of your services are pointing to the mock-up server and you are able to test.
To make it even transparent, place an Apache webserver in front of the OSB/SOA and mock-up server and let Apache decide of the service call is being executed on the OSB/SOA server or on the mock-up server.

With de deploy server (your workstation or a central deploy server) you deploy your OSB and/or SOA artefacts as normally to the server. You also deploy your SoapUI project to the mock-up server.
With Apache you control via rewrite rules if the request for tht service is passed to the OSB/SOA Server or to the mock-up server.

Apache Rewrite
To rewrite your request to the OSB/SOA server or the Mockup server is done in the Apache config file. Create a separate file to read this. Here is an example

#
# This files shows the list of services that are being stubbed/mock-uped.
#

#
# GENERIC, DO NOT CHANGE
#
LoadModule proxy_module modules/mod_proxy.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_http_module modules/mod_proxy_http.so

# Enable rewrite engine
RewriteEngine On
RewriteLogLevel 9
RewriteLog /data/www/logs/stub_rewrite.log
#
#
# OFF: GENERIC, DO NOT CHANGE

#
# Add here your stubbed services
#
RewriteRule ^/MyProject/MyService http://mockupserver.vijfhuizen.com:8080/MyProject/MyService [P]

SoapUI Mockup Server
A lot of discussing is going on on the SOapUI mockup server how to start and stop it as a background process. Here is a script to stop and start this in  the background.
#!/bin/bash
#
# soapui_mockupserver: Start the Eviware SoapUI Mockup Server
#
# chkconfig: 23 99 5
# description:  Start the Eviware SoapUI Mockup Server
#
#

# Source function library.
. /etc/rc.d/init.d/functions
SOAPPID=`ps -ef | grep mockservicerunner.sh | grep -v grep | awk ' { print $2 }'`
BAD_USER="This script should be run as root or as weblogic user. Exiting......."

if [ "$USER" != 'root' -a "$USER" != 'weblogic' -a "$USER" != '' ]; then echo $BAD_USER && exit 1;fi

if [ "$USER" == 'root' -o "$USER" == '' ]; then SOAPUI_DIR=`su - weblogic -c 'echo $SOAPUI_DIR'`;fi

cd $SOAPUI_DIR/bin

start()
{
        echo -n $"Starting $0"
        if [ "$USER" == 'root' -o "$USER" == '' ]; then
          su -c 'nohup $SOAPUI_DIR/bin/mockservicerunner.sh /data/mockup/mockup-services-soapui-project.xml -p 8080 -Djava.awt.headless=true -f /data/mockup/output 2>&1 &' - weblogic
        else
                 nohup $SOAPUI_DIR/bin/mockservicerunner.sh /data/mockup/mockup-services-soapui-project.xml -p 8080 -Djava.awt.headless=true -f /data/mockup/output  2>&1 &
        fi
        echo
  echo "Restart Apache gracefully..."
  for i in `ls /etc/init.d/*fon`
  do 
    echo $i graceful
    $i graceful
  done
}

stop()
{
        echo -n $"Shutting down $0"
        for i in `ps -ef | grep soap | grep -v $0 | awk ' { print $2 }'`
        do
          echo -n " $i"
          kill -9 $i
        done
        unset SOAPPID
        echo
}

# See how we were called.
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart|reload)
        stop; start
        ;;
  condrestart)
        stop; start;
        ;;
  status)
        if [ $SOAPPID ]; then echo "Running"; else echo "Not running";fi
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|reload|condrestart}"
        exit 1
esac

exit 0

2 comments:

vi said...

thanks for making commentable your posts. It is a good solution in case of a simple construction. What happens when your service uses another service (deployed also into the same ESB) and calls forward? It's call should be routed to the apache that selects the ESB or the soapUI. Actually i do not see the reason for introducing a new component with a feature of call routing when the ESB already has inherently this feature. Do you regularly change the ESB implementation that changes the way of configuring it?
I have a dream that EBSs will get the knowledge that a service has more than one implementation and these implementations can be group into production and mock groups at least. In this case the configuration before running a test would be selecting the service under test and it automagically selects all other services to be the mock one. An other branch of ESB development can be when ESB can be configured through a webservice. And later this webservice become a common standard.

Marc Kelderman SOA Blog said...

It depends what the service does. If your service calls anotherone within your service, it is calling a different endpoint. You could change the endpoint, or in my solution, you force Apache to rewrite this service to the mockup server.

Post a Comment

Post a Comment