Prooph LINK module that provides default functionality for a prooph LINK application
Open Issues: 4
- php: >=5.5
- beberlei/assert: ~2.0
- codeliner/array-reader: ~1.1
- doctrine/doctrine-orm-module: ~0.8.0
- mathiasverraes/classfunctions: ~1.0
- phly/mustache: ~1.2
- prooph/event-store-doctrine-adapter: ~1.0
- prooph/processing: ~0.4
- prooph/proophessor: ~0.3
- rwoverdijk/assetmanager: ~1.4
- zendframework/zendframework: ~2.3
- zfcampus/zf-api-problem: ~1.0
- zfcampus/zf-content-negotiation: ~1.0
- phpunit/phpunit: 3.7.*
This package is auto-updated.
Last update: 2023-03-16 21:57:35 UTC
Application core for prooph LINK
The main purpose of the module is to provide an API to create and maintain a processing configuration. The API is command based meaning other modules can use the available commands to add or modify different parts of the application wide processing configuration. Every change is also recorded with a related event, so modules can react on configuration changes and act accordingly.
System Set Up
The system set up is also handled by this module. When starting a fresh installation of prooph LINK, the dashboard will only contain the app-core widget.
Via the widget the user can start a installation routine which creates a new
processing.local.php config file in
By default this file is ignored by GIT, because it contains dynamic configuration only valid for the current installation.
However, when you want to develop a custom version of prooph LINK specific for your project, typically you want to track all changes.
In this case you should adjust the .gitignore file in the config dir.
The set up routine also configures the default application and event store database. It is a SQLite filesystem DB located in
By default the application and event store share the same database. However, this can be changed manually via configuration. The event store manages the process stream
used by prooph/processing. It contains all processing events like started and finished processes and so on. The application DB is used by prooph LINK modules to store
additional information like a message log which is required to monitor the application.
Additionally to the configuration management the app-core module provides a tick mechanism. A TickOccurred event can be triggered from the outside world which is then published via the application event bus. Message dispatcher for example can listen on such a TickOccurred event and pull pending messages from a worker queue.
One possibility to trigger a TickOccurred event is by activating the Javascirpt Ticker shipped with the app-core module. You can activate the ticker in the
System Configuration menu
your settings. The web worker has the advantage that you can switch to another tab in your browser and the worker continues its task. As long as you don't close the application
the ticker will work. You will recognize a new item in the header navbar after activating the ticker. The icon color is changed to blue during a tick request. When you are waiting for a process to finish
you can look at the icon. Every time a tick is send the next step of the process should be executed. If something goes wrong the ticker will inform you with a notification. In such a case
you should also have a look at the process monitor.
Workflow Processor Message Queue
It is possible to activate a general message queue for all messages send by the workflow processor. For details about the processor please referrer to the prooph/processing documentation. The advantage of enabling the message queue is that you can make use of asynchronous worflow processing without the need to set up it for every process. Disadvantage is that you have to make sure that the amount of data per message can be handled by the system so you have to process large data sets in chunks which makes your processes slower but also saver because you won't hit execution time or memory limits. If you want to get the full power out of prooph/processing it is recommended to not enable the general message queue but instead set up asynchronous message handling for every process individually. How this can be done is described in the documentation of the process-manager module.
- Ask any questions on prooph-users google group.
- File issues at https://github.com/prooph/link-app-core/issues.
You wanna help us? Great! We appreciate any help, be it on implementation level, UI improvements, testing, donation or simply trying out the system and give us feedback. Just leave us a note in our google group linked above and we can discuss further steps.
Thanks, your prooph team