Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


For an html version of this readme run 'asciidoc README.asciidoc'.

DTGov Demos: Maven Project Workflow Integration


This demo shows how teams can collaborate using a ProjectLifeCycle Workflow. In this example we have a simplified Project workflow with only three phases with their respective teams. Each team delivers a set of deliverables which are uploaded to the repository. Each upload triggers a review of the artifacts. The artifacts are 'groupedBy' an 'ArtifactGrouping' which is represented as a parent in S-RAMP.

This demo contains three submodules:

  • project-requirements: a requirements doc created a Business Analyst.

  • project-service-api: a service design created by a SOA-Architect.

  • project-service-impl: the service implementation created by a SOA Developer.

The overlord.demo.ProjectLifeCycle.bpmn resides in the dtgov-workflow.jar in the SRAMPPackage and this should already be deployed. Also the classification ontologies should already have been installed as part of the data seeding process during install of DTGov. In the s-ramp-ui artifacts screen you can click on 'Classifiers' to check that the Project Review Status is present.

Project Review Status Ontology
Figure 1. Project Review Status Ontology.

These classifications will be applied by the 'Classify' nodes in the workflow as the project moves through its lifecycle.

Project Workflow
Figure 2. Project Workflow.

You can create and update workflows using the Eclipse BPMN Editor, which can be installed from http://download.eclipse.org/bpmn2-modeler/updates/kepler/0.2.7. The project starts with a business analyst creating a requirements document, which is then reviewed and approved. On a successful approval a SOA-Architect creates a design, followed with another review meeting and finally a SOA-Developer creates an implementation of the design. When the implementation is reviewed the Service Implementation can be released into a formal QA process. The 'Deployment Process' of an Artifact is covered in the dtgov-switchard demo.

How It Works

Starting the Simplified ProjectLifeCycle Workflow

To get this demo working you must be running the DTGov server and the S-RAMP repository (see documentation for the DTGov and S-RAMP projects to learn how to run the S-RAMP repository).

Before starting this demo you need to make sure the project’s poms are in your .m2 repository as one submodule depends on another. From the root of the dtgov-demos run

        $ cd <dtgov-demos>
        $ mvn install

When the Business Analyst finishes the requirement doc project-requirments/src/main/resources/requirements-doc.txt. The next step is to build and deploy the 'requirements' archive to S-RAMP using Maven:

	$ cd project-requirements
	$ mvn -Pdemo clean deploy
Note About Authentication

Be aware that you must supply the maven build with credentials for your S-RAMP repository. This can be done by adding a section to your settings.xml file (or by providing a custom settings.xml on the mvn command line using the '-s' argument).

For more information see: http://maven.apache.org/settings.html

Your settings.xml file should contain two additional server entries in the servers section:

Results of the Deploy

That will enable the 'demo' profile, which will configure the Maven distributionManagement to point to a local S-RAMP repository (http://localhost:8080/s-ramp-server/). Therefore you need to be running S-RAMP on port 8080 and deployed as the 's-ramp-atom' context.

The build should complete successfully.

At this point there should be a number of artifacts stored in the S-RAMP repository. You can verify that by deploying the "s-ramp-ui" project and then navigating to http://localhost:8080/s-ramp-ui (or the appropriate URL for you).

You should see the following artifacts in the S-RAMP repository:

  • dtgov-demos-project-requirements-<version>.jar

  • dtgov-demos-project-requirements-<version>.pom

  • Project-org.overlord.dtgov.demos.project.<version>

The requirements-doc.txt is shipped in the requirements-<version>.jar. Note that you can use other formats if you like. You may have expected the jar and the pom, but what created the 'Project-org.overlord.dtgov.demos.project.<version>' artifact? In the dtgov-demos-project/pom.xml you may have noticed the following section:

      <name>S-RAMP Releases Repository</name>
      <name>S-RAMP Snapshots Repository</name>

This section is active when using the 'demo' profile, and in it we specified an artifact grouping artifactGrouping=Project-${project.groupId}.${project.version}. During the upload this ArtifactGrouping artifact is created along with groupBy relationships to this parent artifacts. The dtgov.properties file defines the following :

governance.queries=/s-ramp/ext/ArtifactGrouping[xp2:matches(@name\, 'Project.*')]|overlord.demo.SimplifiedProjectLifeCycle|UpdateMetaDataUrl={governance.url}/rest/update/{name}/{value}/{uuid}

This starts a overlord.demo.SimplifiedProjectLifeCycle workflow when a ArtifactGrouping with a name that starts with 'Project' lands in the repository. When the workflow is created you should see a new custom property on this artifact which should look like


If you where to delete this property then a new workflow will be started, and a new property will be recreated.

Signaling 'Analysis Docs Complete'

The upload of the requirements also triggered an AnalysisArtifactsComplete signal to the newly created workflow, to signal the workflow that the requirements docs are ready for review. This signal was triggered by upload of the project-requirements/pom.xml. Note that in this pom we have the following properties section


During a MavenPom upload all properties are extracted and added as custom properties, prefixed with maven.property.; so the signal property end up as maven.property.signal with value AnalysisArtifactsComplete. When DTGov discovers this signal property it looks up the accompanying workflow referenced in the Project* ApplicationGroup artifact signals this process instance. After sending the signal the name of the property changes to _maven.property.signal.sent. When the signal is 'caught' by the workflow, it will classify the Project* ApplicationGroup artifact with the #BaInReview classification, and start a Business Analysis Review Meeting task. This task is assigned to the ba role. You can defined roles in the standalone/configuration/overlord-idp-roles.properties. These roles can be referenced in the human task definition as the 'groupId'.

By default the standalone/configuration/overlord-idp-roles.properties looks like


The admin user has all roles. So when logged in as admin you can work on ALL tasks. For this example the ba, arch, and dev roles in use. More roles can be created as needed.

You can work on your tasks by navigating to http://localhost:8080/dtgov-ui#taskInbox. After you’ve reviewed the requirements documents with all stakeholders, you go here to Claim, Start and record the Pass/Fail verdict. For the 'Business Analysis Review Meeting' task you will need the 'ba' role. On a Fail the workflow records the fail and loops back so that a new version can be submitted. On a Pass the workflow records the pass and enters the 'waiting for architecture docs complete' state.

Signaling 'Architecture Docs Complete'

The architect can now take the detailed and approved requirements:

Requirements Document
We have a pressing need for an Hello World Service.
Please develop one that can print "Hello World" when invoked.

and turn them into a design. At a minimum, for this webservice an annotated interface or a WSDL should be created. Both of these can be found in the project-service-api module. Since these are ready to go, proceed with deploying them to S-RAMP using:

	$ cd project-service-api
	$ mvn -Pdemo clean deploy
Results of the Deploy

The build should complete successfully.

You should see the following newly created artifacts in the S-RAMP repository:

  • dtgov-demos-project-service-api-<version>.jar

  • dtgov-demos-project-service-api-<version>.pom

In this pom the signal property


will cause a ArchitectureArtifactsComplete signal to be send to the project workflow signalling that the design documents are ready for review. A review meeting should be called and someone with the 'arch' role can pick up the 'Design Review Meeting' task in the http://localhost:8080/dtgov-ui#taskInbox.

Signaling 'Service implementation Complete'

Finally, when the SOA-Developer has finished the implementation, it can be uploaded to the repository using

	$ cd project-service-impl
	$ mvn -Pdemo clean deploy
If this step fails you may have forgotten to run 'mvn install', as decribed in the beginning of this reade.
Results of the Service Deploy

The build should complete successfully.

You should see the following newly created artifacts in the S-RAMP repository:

  • dtgov-demos-project-service-impl-<version>.jar

  • dtgov-demos-project-service-impl-<version>.pom

In this pom the signal property


will cause a ServiceImplArtifactComplete signal to be send to the project workflow signalling that the design documents are ready for review. A review meeting should be called and someone with the 'dev' role can pick up the 'Service Implementation Review Meeting' task in the http://localhost:8080/dtgov-ui#taskInbox.

This completes this demo.