openwms / org.openwms.tms.routing Goto Github PK

The Matrix should search for the AS_NEXT target and respond with a RES_ message

FeignClients are created in a separate ApplicationContext and not accessible from the root ApplicationContext

In a first place means in Java code.

Currently routing happens basically dynamically on the workflow. For simple layouts we should also provide a static routing table for point-to-point routing capabilities.

Currently the message handling is tightly coupled to the OSIP protocol and new telegram drivers require the need to extend the classpath with own strategies.

At least we could merge the OSIP handlers to simplify the processing code and probably the extension code. Pretty sure that arbitrary message structures still require a custom handling.

Like a ApplicationContextElResolver is able to resolve Spring beans we need to have something similar that translates http commands and HATEOS links to microservice calls.

GET tms-services/orders/4711
POST tms-service/orders

These kind of "expressions" may used in BPMN Activiti expressions

after mvn package and java -jar target/openwms-tms-routing-exec.jar
the ui page of REACT_APP_PUBLIC_URL=http://localhost:8130/ui still can't be visited but found 404 .

at least a widget should be implemented to display:

• all programs
• all routes
• all actions

When the Route UI is built the backend integration needs to be done. The UC are the same as they are for the Route UI.

Current situation
The bootstrapped Activiti workflow engine loads workflow files over the standard Spring Resource patterns file:, classpath: and classpath*:. The important configuration file to have a look at is org.activiti.spring.boot.AbstractProcessEngineAutoConfiguration. Fortunately the author uses an autowired org.springframework.core.io.support.ResourcePatternResolver that can be extended for custom needs. In our case we don't want to load workflow files from the classpath nor from local files, we need to fetch them from a Spring Cloud Config Server. That guy offers a http interface to interact with, and is able to grab requested files from a Git repository.

Proposed Solution
Our service acts as a client of the Spring Cloud Config Server and therefor needs to interact with the http API to fetch demanded workflow files. We need to implement org.springframework.core.io.support.ResourcePatternResolver, at best extends the org.springframework.core.io.support.PathMatchingResourcePatternResolver and access the Config Server on demand.

Requirements to be considered in version 1

• BASIC auth to the config server. Username/password can be taken from the metainf of the spring.cloud.config.* namespace
• The protocol http/https must be taken from the discovery client config map (eureka.instance.metadata-map.config-protocol) because it is not a property of spring.cloud.config.* and a use of spring.cloud.config.headers.* is a misuse

openwms-tms-routing- exec.jar It does not exist under the target path. The existing jar package does not have a manifest attribute, and the startup class cannot be found

Currently support of Flowable has been disabled cause of flowable/flowable-engine#3169

In the current version the processing engine only supports a RESTful API. We now need to support asynchronous message handling, too. The OSIP driver is already capable to send AMQP messages.

In this first iteration a User shall be able to:

• Create new Routes
• Edit existing Routes
• Change Route status
• Delete existing Routes

All without backend integration, just UI logic only

Implement errResponder to handle OSIP ERR_ messages and respond with key osip.err.mfc