- Fast file transfers
- Flow component stacking re-imagined with more configuration
- Improved performance and stability for management storage
- Flexible portal node configurations by the integration environment
- Improved API Design
- Feature-rich HTTP client
- More quality logging
- Reduction of technical debt
- Code documentation
- Peek into the future for administrators
Two weeks ago we released the first 0.9 version. To be more specific it is 0.9.0.0 and so the first version following the new version scheme described in this ADR. Updated changelogs for your updating strategy can be found in the release news section. Let's get more detailed and hydrate the TL;DR above.
The file references are a new way to transfer files with the focus on availability via HTTP and reduction of I/O operations in the HEPTAconnect installation. The datasets and portals have been updated accordingly to use the new performant transport. See a sample usage here.
Flow component stacks
Flow components are now loaded deferred and only grouped when used. This allows portal extensions to provide as much flexibility as portals in terms of flow components. New flexibilities are also given to portal extension developers and administrators as portal extension can now be deactivated on a stack and declared as optional.
Normalization of storage actions
We restructured the internal management storage handling to ensure the stability and performance it deserves. This includes a new package full of test scenarios against the storage base interfaces to allow also pre-built tests for any future storage provider. Read more here.
Flexible portal node configuration
New utilities for integrators are now available to build automatically assigned portal node configurations by patterns. This enables various configurations sources like JSON files from hosting services or environment variables. Read more here.
We provide a new service for portals to make HTTP API usage a step easier. The PSR-18 compatible
HttpClientContract is preconfigured to throw exceptions for 4XX and 5XX status codes, add missing headers, follow redirects and retry in case of an error or rate limit.
When a flow component is put into the log context it will be swapped out with its code origin. This supports navigation to the source of an error, that is not identified by an exception.
All our storage implementations start to add some form of unique identifier to the request, so it can be found more easily in the source code when found in logs.
Even more log messages we write and exceptions we throw have unique identifiers for quick search in the code and in the online changelog.
Jobs have a state history that can be inspected for processing and performance analysis.
The dependency version range is changed to keep everything up to date. This affects
dragonmantank/cron-expression as library usage has been updated to match known deprecations and raised or removed. Read more about its details in the changelogs.
As HEPTAconnect is looking to achieve a state-of-the-art experience on using our API, we improved our API design by ensuring to use
final more frequently without removing extensibility. To ensure code documentation browsing is easy, we add it to a lot of places within the code. Even small subtleties are taken into account like
$this in short notation flow components now refers to the wrapping object-oriented flow component.
Everyone managing an HEPTAconnect instance on setup can now use
heptaconnect:router:add to also create a route in the reverse direction. More CLI commands are supporting JSON output for easier scripting use. Spoiler alert: There is a huge change coming to raise the quality bar for administrator tools in the not so distant future.
Follow the news section by subscribing to the RSS feeds:
Or follow us on Twitter to get more insights on the briefly touched topics in here in the future.