November 6 2017

Starting Up

An important benefit of Continuous Integration is the feedback it provides to the development team after the code is checked into "trunk", or in Git when pushed to the development branch.  The use of SoapUI to create web service tests is fairly typical in most organizations and is considered the de facto standard testing tool in SOA.  This blog address the uses of the SmartBear Maven plugin and best practices around incorporating it into SOA 12c projects.

Plugging the Project POM

In the section below there are two plugins for testing (SoapUI and SureFire) were used by the project POM.  Rather than adding them directly to the project POM create a separate parent POM and inherit it in the project POM.  See this blog topic for more details about using parent POMs in SOA projects.  

Let's cover the SoapUI plugin first.  There are two items worth mentioning about it:

  • The "endpoint" property references the endpoint property defined in the project POM and that will be used for service endpoint of the test in the SoapUI project.
  • The dependency to com.jgoodies is to overcome a missing class in 5.2.1 SoapUI plugin distribution.
  • The execution of the plugin is predicated on the "integration-test" phase, as it is an integration test.


    How does one get the SoapUI Maven artifacts for the above plugin?  Add the following profiles to the Maven settings.xml and be sure to activate them.  Obviously the Smartbear-Profile will pull in the SoapUI plugins.  The Maven-Central-Profile will pull in the SureFire plugin and its dependencies.


    The second testing plugin is the SureFire plugin, to produce HTML report output from the XML created by the SoapUI plugin.  SureFire can then be set to fail if the tests are not entirely or partially (it's configurable) successful.

    • The SureFire plugin will execute in the "verify" phase so it succeeds the steps that deploy the SOA composite and run the SoapUI tests.  
    • The plugin will parse XML output files produced by the SoapUI plugin, contained in the "soapui-output" directory (located in the SOA composite project directory).  
    • The HTML report will be created in the same SoapUI output directory as a file named "...TEST...html".  

    Running the SoapUI Tests

    The SOA Composite project Maven "verify" phase is run that deploys the composite (pre-integration-test), runs the SoapUI tests (integration-test) and lastly runs Surefire to produce the HTML output and produce an error if they fail to run successfully.  The "env" argument shown below is used by the custom parent POM to retrieve properties for the deployment, that live in a file named "" that is included with the application.

    mvn verify -Denv=Local-Docker

    In the Maven output below the test results are summarized via the use of the "printReport" property in the SoapUI plugin.

    SoapUI 5.2.1 Maven2 TestCase Runner
    16:52:44,914 INFO  [DefaultSoapUICore] Creating new settings at [C:\Users\GREG\soapui-settings.xml]
    16:52:45,850 INFO  [PluginManager] 0 plugins loaded in 2 ms
    16:52:45,851 INFO  [DefaultSoapUICore] All plugins loaded
    16:52:46,603 INFO  [WsdlProject] Loaded project from [file:/D:/GregHughlett/jdeveloper/mywork/SoaScaTestApp/SoaScaTest/soapui-project/simple-test-soapui-project.xml]
    16:52:46,610 INFO  [SoapUITestCaseRunner] Setting project property [messageToSoa] to [Hello from POM]
    16:52:46,611 INFO  [SoapUITestCaseRunner] Running SoapUI tests in project [simple-test-soapui-project]
    16:52:46,612 INFO  [SoapUITestCaseRunner] Running TestCase [SendMessageToSoa]
    16:52:46,635 INFO  [SoapUITestCaseRunner] Running SoapUI testcase [SendMessageToSoa]
    16:52:46,646 INFO  [SoapUITestCaseRunner] running step [sendMessage]
    16:52:46,835 DEBUG [HttpClientSupport$SoapUIHttpClient] Attempt 1 to execute request
    16:52:46,836 DEBUG [SoapUIMultiThreadedHttpConnectionManager$SoapUIDefaultClientConnection] Sending request: POST /soa-infra/services/default/SoaScaTest/soascaprocess__ep HTTP/1.1
    16:52:46,930 DEBUG [SoapUIMultiThreadedHttpConnectionManager$SoapUIDefaultClientConnection] Receiving response: HTTP/1.1 200 OK
    16:52:46,935 DEBUG [HttpClientSupport$SoapUIHttpClient] Connection can be kept alive indefinitely
    16:52:47,042 INFO  [SoapUITestCaseRunner] Assertion [SOAP Response] has status VALID
    16:52:47,043 INFO  [SoapUITestCaseRunner] Assertion [Contains] has status VALID
    16:52:47,049 INFO  [SoapUITestCaseRunner] Finished running SoapUI testcase [SendMessageToSoa], time taken: 386ms, status: FINISHED
    SoapUI 5.2.1 TestCaseRunner Summary
    Time Taken: 27056ms
    Total TestSuites: 1
    Total TestCases: 1 (0 failed)
    Total TestSteps: 1
    Total Request Assertions: 3
    Total Failed Assertions: 0
    Total Exported Results: 0
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 01:21 min
    [INFO] Finished at: 2017-07-03T16:09:09-04:00
    [INFO] Final Memory: 29M/323M
    [INFO] ------------------------------------------------------------------------

    Finishing Up

    There are a number of best practices to be recommended here, to provide flexible uses of SoaUI projects in local Integrated WebLogic and DEV deployments.

    • Have developers who create the SoapUI projects standardize on their version of SoapUI, to eliminate differences an older or incompatible release may create.  
    • Create a "soapui-project directory" in the JDeveloper workspace directory.  The configuration of the SoapUI plugin can then reference it relative to ${basedir}.

    • If targeting an SSL SOA environment then be sure to add the keystore with the server certificate imported (e.g. DemoTrust.jks) before importing the WSDL URL to create the SoapUI project.  Be sure to also include the keystore in the newly created project.

    Add keystore to preferences

    • There may be occasions when you may want to deploy the project but not run any of the test steps associated with SoapUI or Surefire.  Simply include this property on the Maven command line.



    About the Author

    Greg Hughlett

    Greg has more than twenty-five years of experience in all phases of design, development, and implementation of software applications.  He has developed and architected BPM/SOA technologies for more than ten of those years from Fuego BPM to BEA AquaLogic BPM to Oracle BPM/SOA 11g.  He has worked for clients within banking, financial services, Life Insurance,  Health Care, public sector and telecommunications industries.  His areas of expertise include Oracle SOA and Oracle BPM (formerly AquaLo

    Join the Conversation

    Enter your first name. It will only be used to display with your comment.
    Enter your email. This will be used to validate you as a real user but will NOT be displayed with the comment.