Skip to content

3 Using microservices

Paul Pound edited this page Sep 16, 2013 · 13 revisions

3.1 Create a workflow with Taverna Workbench

3.1.1 Opening an Existing workflow

If we already have a workflow:

  1. Go to file.
  2. Open Workflow.
  3. Navigate to your existing file.
  4. Click “OK”, the workflow diagram and the workflow panel will propagate.

3.1.2 create a new workflow

If we want to create a new workflow, here are the steps that will be performed. Steps:

  1. Choose New workflow from the file menu.
  2. Add services to Taverna.
    • click import new service and then click on WSDL services from the dropdown.
    • Enter the URL of WSDL. Say for an example, you installed the Islandora Soap Services on a server with a domain of service.mydomain.com the services WSDL could be at http://services.mydomain.com/soap_server/soap_serv.php?wsdl
    • Click ok and the service will be added.
  3. To add a service to the workflow, click on one and in the service panel and drag it into the Workflow Diagram or to the tree in the workflow Explorer.
    • Right click on the new service and click choose show ports. This will gives us an idea of what input and output ports we have to work with.
  4. the workflow needs input, For most Islandora workflows we will need a pid and dsid.
    • Right click on the blank area of the workflow Diagram and select insert--> Workflow input port. Enter the name of the port(pid in our case). Click ok and new input appear in the workflow diagram and the workflow Explorer.
    • Do the same thing to create a port for dsid.
  5. Right click on the dsid input port of the service and connect it to either an existing workflow input port like dsid or you can use a constant value you, such as "OBJ". If you use a constant value you can share a workflow with different Fedora apim methods like addDatastream and ingest. Ingest workflows won't get passed a dsid as Fedora does not include a dsid in the JMS message.
    • Most other service input ports will be configured by using constants, such as outputdsid, resize etc., except for pid which must be linked to a workflow input port.
  6. Right click on the pid service input port and choose connect with output from and click pid.
  7. Now to output, Right click on exit_status service output port and choose Connect as input to and then click New workflow output port and choose the default text supplied.

![image](images/example_workflow_diagram - New Page.png)

Optional workflow configuration

In workbench you can also configure things like security, looping and retries.

  • Security * Right click on a Service in the Workflow explorer and choose Configure Security, then click Http username and password authentication. At this point you do not need to set the username and password (that was done when you configured the listeners).
  • Looping
    • Right click on a Service in the Workflow explorer and choose Configure running -> Looping. In the dialog box choose exit_stats is_equal_to and type 0

Since the whole listener/services run asynchronously looping can be useful as a service may fail occasionally if two services try to modify the same object at the same time. If you do not want to use looping you could also try other strategies like run after and chain the services to run one after another. Run after can also be configured by Right clicking on a service in the Workflow explorer.

3.2 Trigger t2flow

3.2.1 Add Trigger-Datastreams to content model

To enable workflows for objects each objects Content Model object must have a datastream named "Trigger-Datastreams" which dictates when each t2flow should be run.

"Trigger-Datastreams" contains method types (e.g ingest, addDatstream, modifyDatastreamByReference, etc.). Inside each method type we can dictate any t2flows that should be run whenever a method occurs.
We can also dictate that a t2flow should only be run when the method occurs on a specific data stream. There are several methods that are supported for the trigger datastreams object.

Available methods are:

  • modifyDatasstreamByValue - modifying a fedora object’s datastream value
  • modifyDatastreamByReference - modifying a fedora object’s datastream content
  • ingest - creating a new fedora object
  • purgeObject - purging a fedora object
  • purgeDatastream - purging individual datastream
  • addDatastream - adding a new data stream

A example Trigger-Datastreams datastream can be find here:

https://github.com/roblib/php_listeners/wiki/Appendix-A-:-An-Example-Trigger-Datastream

E.g A t2flow should be run when a data stream is modified, and that data stream's dsid is "OBJ".

You can add a Trigger-Datastreams data stream to a Content model in either Islandora or the Fedora Admin client by opening the appropriate object and choosing to add a data stream, see 3.2.2 for details.

3.2.2 Add Workflow to an content model

Adding a T2Flow document created in the taverna workbench to a current content model for future use can be done through the following steps:

  1. Log into the fedora admin server. Default address will look like http://domainname:8080/fedora/admin however this may vary depending on fedora installation. Input appropriate credentials to log in.
  2. On the search tab on the right enter the name of the content model. For example: “audio” would be used to search for the audio content model. Select the appropriate option from the drop down menu.
  3. Next, add a new datastream. Enter the information displayed in the image below This should cause a new datastream to be created for the object and allow the t2flow object to be added to the content model. Refresh the data streams.
  4. This can be verified by opening the object’s XML via the view object xml option.

Note: There could be many t2flow documents stored for each content model. They will all be of the type t2flow-doc, however they will have unique identifying dsids or UUIDs. The dsids should match corresponding entries in the Trigger-Datastreams data stream xml

< previous page | next page >