Version 4

    1. Read Workflow Definition from S-RAMP

     

    I'm working on deploying jBPM workflows into S-RAMP governance; these workflows are the governance workflows and can be customized, or new ones can be created. Workflow can be set to kick of for certain repository events. Anyway I'm trying to tell jBPM about a workflow stored in S-RAMP (rather then Drools-guvnor). I'd like to produce a package with a workflow in Drools-guvnor and upload this to S-RAMP.

     

    The jBPM-console uses a rest API to load up the workflow.

    - The Drools-guvnor endpoint config is set in the jbpm-gwt-console-server.war/WEB-INF/classes/jbpm.console.properties

    guvnor.protocol=http

    guvnor.host=localhost:8080

    guvnor.subdomain=drools-guvnor

    guvnor.usr=admin

    guvnor.pwd=admin

    guvnor.packages=defaultPackage

    guvnor.connect.timeout=10000

    guvnor.read.timeout=10000

    guvnor.snapshot.name=LATEST

     

    Using that connection config it uses the GuvnorConnectionUtil to hit the following endpoints:

    i.  /drools-guvnor/rest/packages, (getPackageNames) to get all the packages available in Drools-guvnor (see package.xml for an example resonse). jBPM only cares about the package titles.

    ii. /drools-guvnor/rest/packages/{pkgName}/assets/ to get all the assets in the {pkgName} package (see asset.xml for an example response) jBPM reads each asset and looks for the 'format', 'title' and if the format is bpmn or bpmn2 it takes the title of the asset and adds it to the process list. So it returns the list of bpmn(2) workflows in this package where the title is the processId.

    iii. /rest/packages/{pkgName}/binary, Next when you start a new process instance (in the jbpm-console) it fetches the {pkgName}.pkg.

    iv. /org.drools.guvnor.Guvnor/package/{pkgName}/{guvnor.snapshot.name}/{templateName}.drl if there are any forms associated with the workflow, forms are not in the pkg and are downloaded separately.

    v. /org.drools.guvnor.Guvnor/package/{pkgName}/{guvnor.snapshot.name}/{processId}-image to obtain the image of the process definition. images are not in the pkg archive  and are downloaded separately.

     

    I believe these are all endpoints jBPM hits: 3 of them are the 'rest' and 2 are the 'org.drools.guvnor.Guvnor' API.

     

    2. Uploading and mapping a (workflow) package to S-RAMP

     

    A pkg is a binary artifact, which can be uploaded as a document. Next we will have to a collection of assets related (in) this package. For the time being the asset information only needs to contain the title and the format (bpmn/2, maybe format is the mimeType, an example of the full asset looks like

     

    <asset>

      <author>guest</author>

      <binaryContentAttachmentFileName></binaryContentAttachmentFileName>

      <binaryLink>http://localhost:8080/drools-guvnor/rest/packages/defaultPackage/assets/Evaluation4/binary

      </binaryLink>

      <description></description>

      <metadata>

       <checkInComment>dd</checkInComment>

       <created>2012-09-04T17:47:16.902-04:00</created>

       <disabled>false</disabled>

       <format>bpmn</format>

       <note>&lt;![CDATA[ dd ]]&gt;</note>

       <state>Draft</state>

       <uuid>3d8c8abe-8f77-4e8f-9c9d-983a474f2973</uuid>

       <versionNumber>6</versionNumber>

      </metadata>

      <published>2012-09-06T14:19:18.877-04:00</published>

      <refLink>http://localhost:8080/drools-guvnor/rest/packages/defaultPackage/assets/Evaluation4

      </refLink>

      <sourceLink>http://localhost:8080/drools-guvnor/rest/packages/defaultPackage/assets/Evaluation4/source

      </sourceLink>

      <title>Evaluation4</title>

    </asset>

     

    We do need to store forms and images in S-RAMP alongside the pkg file, as they not part of the pkg and are accessed using the rest API at the asset level. In other words, upload the pkg, then followed by a batch or zip upload of the form(s) and image(s) used by the assets in the package. We need to add the rest endpoints mentioned above to mimic the endpoints used by the jbpm-console to get its info from Drools-guvnor.

     

    Also we do have to add a category so we know if this package is approved and 'live' for a certain runtime. Until then the endpoint should return a not exits (404).

     

    Bonus points; we could suck in more info from Drools-guvnor as supporting documentation etc during the upload process.

     

    3. Publish a workflow to jBPM

     

    Instead of having jbpm point to Drools-guvnor we'd point it to S-RAMP by updating the Drools-guvnor endpoint config is in the jbpm-gwt-console-server.war/WEB-INF/classes/jbpm.console.properties:

     

    guvnor.protocol=http

    guvnor.host=localhost:8080

    guvnor.subdomain=s-ramp-atom/brms

    guvnor.usr=admin

    guvnor.pwd=admin

    guvnor.packages=overlordGovernancePackage,defaultPackage

    guvnor.connect.timeout=10000

    guvnor.read.timeout=10000

    guvnor.snapshot.name=LATEST

     

    Note that you would have liked the capability to set the release version per package. At the moment the version (drools snapshot) can only be set 'globally' and is LATEST by default. For now we may have to bake the version into the packageName (defaultPackage_1_0), or we could use the status field to assign the release version. Problem remains though that jbpm does not specify any version info when accessing the pkg endpoint, so it looks like baking it into the package name is our only option. It's ugly we have to change the jbpm.console.properties file to push a new version of a package. So for now I think we will just have to gran the most recent (LATEST) until we can discuss this issue with the Drools team. So for now when an artifact is 'live' in S-RAMP it will be picked up by jBPM. We will use the 'overlordGovernancePackage' for all governance workflows in use by S-RAMP Governance.

     

    4. S-RAMP Governance Event starts a Governance Workflow

    The Goverance layer will have a customizable mapping of eventtype to start/stop a workflow. For S-RAMP governance to start a process instance there is yet another RestAPI:  http://localhost:8080/gwt-console-server/rs/server/resources/jbpm, attached in pdf form.

     

    5. Drools-guvnor Issue list

     

    1. It would be much, much nicer if drools uses zip rather then java serialization to create drools packages.

     

    2. Drools-guvnor comes with more then one REST api,

    a. one is bound to org.drools.guvnor.Guvnor: http://localhost:8080/drools-guvnor/org.drools.guvnor.Guvnor/package/defaultPackage/LATEST

    b. the other one is bound to rest: http://localhost:8080/drools-guvnor/rest/packages/ (some info on this at http://blog.athico.com/2011/03/atompub-interface-for-guvnor.html)

    where the second API is atom based and is fairly complete, however it is clearly targetted to IDE type features such as adding assets, keeping track of versions (note that in drools context a version is how many times you saved a file). The first API is older and deals more with deploying a package. In drools context a snapshot is a 'frozen' picture of a package, so it's opposite the maven terminogy where that would be called a 'release version'.

     

    3. You should be able to specify the release version for every package in the jbpm-console configuration.

     

    4. There should a be REST endpoint to list all the release versions (Drools snapshots) for a package.

     

    5. Images and forms (all assets needed) should be IN the pkg, and there should be no need to download them separately, and if the pkg is a zip format it would be easier to extract the create the derived artifacts from just the pkg.