This will provide increased explication and isolation and enable an extractor to specify multiple properties to enhance, as well as declaring what key should be utilized in the resulting object.

There should be an enum on the ExtractorTask MergeStrategy mergeStrategy with values MERGE and CONCAT etc. In addition to the MergeStrategy mergeStrategy property there should be a String predicateProperty to supply resulting merge strategies with the appropriate key to predicate logic upon.

2022-08-18 21:51:04.968 INFO 6 --- [nio-8081-exec-4] o.folio.rest.workflow.jms.EventProducer : Send [event.queue]: POST, /events/workflow/hathitrust/start, null
2022-08-18 21:52:24.580 INFO 6 --- [nio-8081-exec-6] o.folio.rest.workflow.jms.EventProducer : Send [event.queue]: POST, /events/workflow/orcid/start, {"emailTo":"[email protected],[email protected],dhahn.library.tamu.edu"}
2022-08-18 21:56:15.850 INFO 6 --- [nio-8081-exec-1] o.folio.rest.workflow.jms.EventProducer : Send [event.queue]: POST, /events/workflow/orcid/start, {"emailTo":"[email protected]"}
2022-08-19 00:15:20.124 INFO 6 --- [nio-8081-exec-2] o.folio.rest.workflow.jms.EventProducer
2022-08-19 00:27:29.468 INFO 6 --- [nio-8081-exec-4] o.folio.rest.workflow.jms.EventProducer
2022-08-19 00:31:05.783 INFO 6 --- [nio-8081-exec-6] o.folio.rest.workflow.jms.EventProducer
2022-08-19 00:34:40.095 INFO 6 --- [nio-8081-exec-8] o.folio.rest.workflow.jms.EventProducer
2022-08-19 01:07:39.797 INFO 6 --- [io-8081-exec-10] o.folio.rest.workflow.jms.EventProducer
2022-08-19 01:12:43.333 INFO 6 --- [nio-8081-exec-2] o.folio.rest.workflow.jms.EventProducer
2022-08-19 01:14:11.995 INFO 6 --- [nio-8081-exec-4] o.folio.rest.workflow.jms.EventProducer

https://github.com/TAMULib/mod-workflow/blob/main/service/src/main/java/org/folio/rest/workflow/jms/EventProducer.java#L27

Please remove the log!

UI: https://folio-dev-tamu-diku.ci.folio.org/

Okapi: https://folio-dev-tamu-okapi.ci.folio.org/

Edge: https://folio-dev-tamu-edge.ci.folio.org/

Sip2: https://folio-dev-tamu-sip2.ci.folio.org/

https://dev.folio.org/faqs/how-to-get-started-with-rancher/

This is blocked by: #113

Update: workflows for the tamu tenenat:

• circ-fines
• coral-extract
• create-tags
• e-resource
• gobi
• hathitrust
• item-history-update
• medsci-gps-zone
• orcid
• patron
• purchase-orders
• rapid-electronic-monos
• rapid-electronic-serials
• rapid-print-monos
• rapid-print-serials
• shelflist-holdings
• shelflist-items

folio-test - does not have the following:

• item-history-update
• shelflist-holdings
• shelflist-items

Mod workflow should allow for the creation of a task type to correspond to the camunda delegated described by this issue.

https://issues.folio.org/browse/FOLIO-3636

Currently both the ModCamundaService BpmnModelFactory services have very Camunda centric implementations.

Upon completion of this issue this functionality will have been implemented in Mod Camunda.

Mod Workflow should remove both the ModCamundaService and the BpmnModelFactory and instead post JSON representing the workflow to be activated/deactivated to the relavent enpoint provided by Mod Camunda.

It would be desirable for this communication to be handled by a dedicated service created for that purpose (i.e. WorkflowEngineService)

This can be done by introducing a enum for sort mode (lexicographical or numerical) and adding a property to the EnhancingExtractor for that enum.

Perl should be added to available script types.

This task should allow for the setting of a URL, request body and HTTP Method Verb. Possibly an expected response code.

Currently much of the logging has been handle using System Out. This should be changed to use a logger, and Log Level should be added to the docker file as a configurable environment variable.

Currently there is no way to identify what version of a workflow is running in the workflow engine. When a workflow is activated it should always include a variable with the workflow version.

The property that must be populated is here: https://github.com/TAMULib/mod-workflow/blob/main/components/src/main/java/org/folio/rest/workflow/model/Workflow.java#L40

This work has two main components:

1. Mod Workflow needs to be modified to ensure that the version property is added to all deployed workflows as a process variable.
2. This will also require edits to the FW CLI to pass up the fw-registry commit hash as the version tag for all built workflows.

Version Tag property on w/f
(commit hash of the deployed w/f)

Given the completion of this issue, Mod Workflow should provide an trigger of type EventTrigger.

The functionality of the event trigger will be consistent with the current trigger strategy.

Need a way to version workflows that maintain history amongst all version runs.

Some developers just need to spin up a Docker Container locally to perform tests.
Using H2 seems ideal in this case.

H2 appears to be unsupported because of the failure message below.

The fw build command is failing in mod-workflow when using H2.

$ fw build my-test-workflow
(node:2140) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
failed post http://localhost:9001/mod-workflow/triggers {
  id: '04a4ad57-c205-4c77-b7de-2a5015cd6b58',
  name: "Rajdeep's Workflow Start Trigger",
  description: 'Rest Post Endpoint',
  type: 'MESSAGE_CORRELATE',
  method: 'POST',
  deserializeAs: 'EventTrigger',
  pathPattern: '/events/workflow/my-test-workflow/start'
}
{
  errors: [
    {
      message: 'Could not alter JDBC connection to use schema [tamu_workflow_service]',
      type: 'HibernateException',
      code: '500 INTERNAL_SERVER_ERROR',
      parameters: []
    }
  ],
  total_records: 1
}

The Docker image (built using the build_and_run Dockerfile) is run using the following environment variables and settings:

export SPRING_JPA_DATABASEPLATFORM="org.hibernate.dialect.H2Dialect"
export SPRING_DATASOURCE_PLATFORM="h2"
export SPRING_DATASOURCE_DRIVERCLASSNAME="org.h2.Driver"
export SPRING_DATASOURCE_URL="jdbc:h2:./mod-workflow;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE"
export SPRING_SQL_INIT_PLATFORM="h2"

docker run -d -p 9001:9001 -p 61616:61616 -e "SPRING_JPA_DATABASEPLATFORM=$SPRING_JPA_DATABASEPLATFORM" -e "SPRING_DATASOURCE_PLATFORM=$SPRING_DATASOURCE_PLATFORM" -e "SPRING_DATASOURCE_DRIVERCLASSNAME=$SPRING_DATASOURCE_DRIVERCLASSNAME" -e "SPRING_DATASOURCE_URL=$SPRING_DATASOURCE_URL" -e "SPRING_SQL_INIT_PLATFORM=$SPRING_SQL_INIT_PLATFORM" -e "SERVER_PORT=9001" mod-workflow

This is pending approval for the build_and_run Dockerfile changes.

The recent build and run Dockerfile could be documented.

There is some room for flexibility on how to do this and consulting Jeremy is suggested.

The README in mod-workflow describes the Docker Deployment process. This process needs to be amdended to also communicate that an optional "Build and Run" Dockerfile is available.

Here are two examples of how to do this.

Example 1

Add an additional section such that the ## Additional information source looks like the following:

## Docker deployment

This is the standard FOLIO deployment method.
```
mvn clean package
docker build -t folio/mod-workflow .
docker run -d -p 9001:9001 folio/mod-workflow
```


### Publish docker image

```
docker login [docker repo]
docker build -t [docker repo]/folio/mod-workflow:[version] .
docker push [docker repo]/folio/mod-workflow:[version]
```


## Alternative Docker deployment
The alternative deployment can be used if maven is unavailable on the host system where Docker is being built.

```
docker build -t folio/mod-workflow -f .
docker run -d -p 9001:9001 folio/mod-workflow
```

Example 2

Add an additional section such that the ## Additional information source looks like the following:

## Docker deployment

```
mvn clean package
docker build -t folio/mod-workflow .
docker run -d -p 9001:9001 folio/mod-workflow
```

If maven is unavailable, then the _Build and Run Dockerfile_ can instead be used by adding `-f docker/build_and_run/Dockerfile` to the  build command like this: `docker build -t folio/mod-workflow -f docker/build_and_run/Dockerfile .`. Then the `mvn clean package` step can be skipped.

### Publish docker image

```
docker login [docker repo]
docker build -t [docker repo]/folio/mod-workflow:[version] .
docker push [docker repo]/folio/mod-workflow:[version]
```

Given the completion of this issue, Mod Workflow should provide a trigger of type ScheduleTrigger.

This trigger will accept a cron expression and any workflow with that trigger will begin at the expressed scheduled interval.

As non-enterprise Camunda UI does not offer access to workflow history, we need the ability to fetch workflow history. This should be done from mod-workflow for a given workflow. It then should make requests to mod-camunda's API for the history of a workflow.

This card will account only for the merging.

To support this issue the uniqueBy property, on the StreamCreateForEachTask (formerly CreateForEachTask), should be a string array.

The Workflow entity should have a property boolean isStreaming

Generally this means:

• Update Java in the pom files.
• Check and update dependencies that must be upgraded.
• Check for regression (requires running the services and testing).

Given the completion of this issue, Mod Workflow should provide a trigger of type ManualTrigger.

The behavior of this trigger will be such that an endpoint will be exposed to trigger a workflow referenced by trigger ID

In preparation for submitting Mod Workflow for acceptance by the FOLIO Technical Council, we should identify the work which needs to be done in order for this module to pass evaluation.

The evaluation processes is defined here: https://wiki.folio.org/display/TC/New+Module+Technical+Evaluations
And the evaluation criteria can be found here: https://github.com/folio-org/tech-council/blob/master/MODULE_EVALUATION_TEMPLATE.MD

Currently there is only one type of trigger in Mod Workflow. We desire to have at least three different types of trigger (EventTrigger, ManualTrigger and a Schedule Trigger). In order to do this the trigger entity should employ the same inheritance mechanism as is used by tasks.

Currently, though Mod Workflow has a module descriptor, it is not being registered with OKAPI, and all traffic between mod-workflow and mod camunda is module-to-module, and not going through OKAPI. We need to ensure that Mod Workflow is deployable through okapi via its module and deployment descriptor, and that the communication between modules is routed through okapi.

Currently Mod Workflow is implemented in our own spring-module-core. In FOLIO most exisitng spring modules have been implemented using the EBSCO spring-way implemenation of spring: https://dev.folio.org/guides/spring-way/

We should identify what would need to be done to transition Mod Workflow to using the spring-way approach.

As workflows are initiated through mod-workflow, this is an opportunity to afford validation of the form parts or request body before sending to mod-camunda in which could fail and cause incidents.

When running locally using mvn clean spring-boot:run against a postgresql server an error like the following appears:

Connection cannot be null when 'hibernate.dialect' not set

Adding this to the application.yml fixed the problem:

spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect

This should probably be in the application.yml by default.

This potentially could also be the cause of the problem described here:

• #121

The task will need to have a isMultiple Boolean as well as a mapAs string.

Mod Workflow should allow for the creation of a new entity, StreamMergerTask to correspond with the delegate described here.