Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 2 Current »

For testing we use a sample topology that comprising the following components:

  • WebLogic AdminServer, running camunda, the taskana parse listener, taskListener and outbox rest API, using an Oracle Database

  • Wildfly 12.0 server, running Taskana, the Taskana REST Api and workplace (module taskana-rest-spring-example-wildfly) plus the adapter (module taskana-adapter-camunda-wildfly-example)

Preparation of WebLogic and the Oracle Database.

Please read the description completely before beginning with configuration / installation

Oracle is set up in such a way that Camunda and TaskanaTaskListener / Taskana Outbox Rest use the same database but a different schema. Camunda uses schema ‘camunda’ while the Taskana components use schema taskana_tables. In our tests, we configured taskana TaskListener and Outbox Rest Api to use the camunda datasource for access to the database. For the Outbox Rest Api you might want to use a different datasource. You can do this, but this step is not described here.

Set up comprises the following tasks.

  • Install WebLogic and configure a WebLogic domain with an AdminServer.

  • Prepare oracle database and deploy camunda to the WebLogic AdminServer as described in https://docs.camunda.org/manual/7.7/installation/full/wls/manual/ . This involves creation of schema camunda and the camunda tables as well as the dataSource for camunda.

  • Create a new schema for the outbox tables:

    • Log into SQL Plus (sys as sysdba) and create user TASKANA_TABLES for the outbox schema

      > ALTER SESSION SET "_ORACLE_SCRIPT"= TRUE;
> Create USER TASKANA_TABLES identified by <password for TASKAN_TABLES>

    • Log into SQLPlus as user taskana_tables

    • create schema taskana_tables via taskana-outbox-schema-oracle.sql script from the sql directory of taskana-adapter-camunda-listener-<version>.jar. Before running the script, change
      %schemaName% --> TASKANA_TABLES
      %camundaSchemaName% --> CAMUNDA

    • grant rights to camunda

       GRANT INSERT,UPDATE,SELECT,DELETE ON TASKANA_TABLES.OUTBOX_SCHEMA_VERSION  to camunda;
 GRANT INSERT,UPDATE,SELECT,DELETE ON TASKANA_TABLES.EVENT_STORE  to camunda;
 GRANT CONNECT, RESOURCE, DBA TO camunda

  • Enable Taskana ParseListener and TaskListener:

    • copy taskana-adapter-camunda-listener-<version>.jar to <WebLogicDomainRoot>/lib

    • copy slf4j-api-1.7.30.jar and slf4j-simple-1.7.30.jar to <WebLogicDomainRoot>/lib to enable log entries from the taskana components.

    • find camunda-oracle-weblogic-service.jar in the subtree below <WebLogicDomainRoot>. We found it at <WebLogic-Domain>\servers\AdminServer\tmp_WL_user\camunda-bpm-platform\o3p2c6.
      Edit this jar file, navigate to META-INF and modify META-INF/bpm-platform.xml
      Add the taskana engine plugin:
      <plugin>
      <class>pro.taskana.adapter.camunda.parselistener.TaskanaParseListenerProcessEnginePlugin</class>
      </plugin>
      in the plugins section.
      You might prefer to modify bpm-platform.xml in the downloaded Camunda distribution for WebLogic. In this distribution, you find bpm-platform.xml in the "modules\camunda-oracle-weblogic-ear-$VERSION.ear\camunda-oracle-weblogic-service.jar\META-INF" folder. If you modify bpm-platform.xml in this location, you must do it before you install camunda to WebLogic.

    • Supply an external common property file for the ParseListener, TaskListener and the outbox REST api:

      • create 'properties - directory', e.g. <WebLogicDomainRoot>/taskanaconfig

      • modify <WebLogic-DomainROOT>/bin/setDomainEnv.cmd. 'Un-comment' the line that sets the PATCH_CLASSPATH and edit it so that it points to the fully qualified pathname of the 'properties - direcotory'

      • Place taskana-outbox.properties into the 'properties - directory'. This property file must contain the properties

        • taskana.adapter.outbox.schema (taskana-tables, the schema name of the outbox tables),

        • taskana.adapter.outbox.datasource.jndi (the jndi name of the datasource that can be used to access the outbox tables. You can use camunda's datasource or define an own one).

        • and it should contain the property taskana.adapter.create_outbox_schema=false, since this schema was created manually

  • Start WebLogic and install taskana-adapter-camunda-outbox-rest-<version>.war via the WebLogic admin console


Preparation of JBoss / Wildfly for taskana / taskana-adapter with postgres database

  • configure postgres database and datasource as described in https://taskana.atlassian.net/wiki/spaces/TAS/pages/887226440/Preliminary+Use+PostgreSQL+as+a+Datasource+for+Camunda+BPM
    For the configuration of the datasource, you can also use the <JBoss-home>/bin/jboss-cli shell script. To do this, you start the wildfly / JBoss server and then invoke jboss-cli in the <JBoss-home>/bin directory.
    Use the following commands with the JBoss-cli command prompt (before doing this, you have to place postgresql-42.2.5.jar into the /Driver/ directory):

    ]connect
]module add --name=org.postgres --resources=/Driver/postgresql-42.2.5.jar --dependencies=javax.api,javax.transaction.api
]/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver)
]/subsystem=datasources/data-source=TaskanaDS/:add(connection-url=jdbc:postgresql://localhost:5432/postgres,driver-name=postgres,jndi-name=java:/TaskanaDS, initial-pool-size=4,max-pool-size=64,min-pool-size=4,password=postgres,user-name=postgres)]exit

  • enable elytron security

    <JBoss-home>/jboss-cli.sh --file=<JBoss-home>/docs/examples/enable-elytron.cli

  • create user admin via <DBoss-home>/bin/add-user shell script

  • provide a TaskRoutingProvider as described in https://taskana.atlassian.net/wiki/spaces/TAS/pages/995524621/TaskRouting+Service+Provider+Interface
    Place this TaskRoutingProvider into the taskana-rest-spring-example-wildfly-<version>.war file below directory WEB-INF/classes.
    In addition, a pro.taskana.spi.routing.api.TaskRoutingProvider control file that lives in a subdirectory META-INF/services of the classpath is required in order to register the SPI implementation.
    Place this file into the WEB-INF/classes/META-INF/services directory.

  • Create an application.properties file in <JBoss-Root>/bin/config directory. Specify the following properties:

    • taskana-system-connector-camundaSystemURLs=<camundaSystem1-RestURL> | <camundaSystem1-TaskEventsURL>
      In the reference setup, this is:
      taskana-system-connector-camundaSystemURLs=http://localhost:7001/engine-rest | http://localhost:7001

    • taskana.schemaName=TASKANA

    • taskana.datasource.jndi-name=java:/TaskanaDS

    • spring.main.allow-bean-definition-overriding=true (this property is required)

    • In addition, all properties of the application.properties files of the taskana-rest-spring-example-wildfly as well as the taskana-adapter-camunda-wildfly-example projects can be specified.

  • Deploy taskana-rest-spring-example-wildfly-<version>.war (copy to deploy directory)

  • Deploy taskana-adapter-camunda-wildfly-example-0.9.2-SNAPSHOT.war (copy to deploy directory)

  • Start JBoss / wildfly

  • Have fun. You can now direct your browser to camunda via http://localhost:7001/camunda or to the taskana workplace via http://localhost:8080/taskana.

  • No labels