The new version 1.4.6 of the Imixs-BPMN Plugin is released. The new release includes bugfixes and enhancements. The Imixs-BPMN Report Plugin which is part of the Imixs-BPMN modelling tool now provides a new feature to directly include the content of a XSL file into a report definition:
Reports allow the extraction of information from a Imixs-Workflow instance. Imixs-Workflow provides a flexible REST-API to customize the output of a report. This includes the XSL Transformation. With this feature, workflow information can be transformed in any kind of output, like XML, JSON and also different document formats like PDF or MS-Word or MS-Excel.
The workflow business suite Imixs-Office-Workflow includes a management dashboard with different char diagrams to visualize relevant business process data.
Imixs-BPMN is based on the Eclipse BPMN2 Project. The installation guide for Imixs-BPMN can be found here.
When setting up a Wildfly server, it is possible to use environment variables in the standalone.xml file by using the Bean Shell expression.
See the following example which sets up the database, user and password in a database configuration in the standalone.xml file by accessing environment variables:
<datasource jta="true" jndi-name="java:/jdbc/my_datasource" pool-name="my_pool" enabled="true" use-ccm="true">
With the Bean Shell expression it is not necessary to turning parameters into System Properties: just use the expression:
Especially when running wildfly in a docker container, this can be very helpful, because you can pass through environment variables to the container:
docker run --name="wildfly" -d -p 8080:8080 -p 9990:9990 \
-e WILDFLY_PASS="admin_password" \
-e POSTGRES_USER="my-postgres-user" \
-e POSTGRES_PASSWORD="mypassword" \
-e POSTGRES_CONNECTION="jdbc:postgresql://postgres/mydb" \
Also in combination with docker-compose environment variables can be set in the docker-compose.yml file. See the next example of a docker-compose.yml file, which sets up a postgres service and a wildfly service with a connection pool configuration as defined before in the standalone.xml:
This is an example, which we use in combination with the wildfly docker container provided by the Imixs-Workflow project.
During the past years I saw many projects where nearly any kind of business requirements was modeled into the technical object model, independent of the reason of the requirement. In many cases, modelling business requirements into a technical object model is quite ok and I agree with it in general. But also modelling business requirements into the affected business objects can lead into a ugly and complicated data structure. Let’s look into a short example to illustrate my thoughts: Continue reading “Don’t model Business Behavior in Objects!”