[FOLIO-969] Architecture needs for a "tap" of transactions Created: 06/Dec/17 Updated: 12/Nov/18 Resolved: 27/Aug/18 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Peter Murray | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | devmtg-201801 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | 1 hour | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||
| Sprint: | |||||||||
| Description |
|
It is looking likely that the architecture will need some way to stream transactions to receivers that will transform and do other processing on transaction data. This issue is a discussion of those needs. |
| Comments |
| Comment by Peter Murray [ 06/Dec/17 ] |
|
This need has come up in several contexts:
The crux of the issue is how do we efficiently and effectively get data out of the transaction-oriented Okapi layer and into something that can independently transform/store the transaction data. Given that there is already more than one need for this (bullet points above), we need a general way of handling this. Which leads to these questions:
Lastly, what is the best way to prototype this requirement? |
| Comment by Jakub Skoczen [ 08/Dec/17 ] |
|
Note: even though we do not support a native messaging protocol, a publish/subscribe mechanism can be simulated by Okapi with so-called multiple interfaces (which would model subscribers) and regular "requires" dependency (to model publishers). What we are missing is a more flexible way to multiplex the requests and collect errors. This could be implemented in Okapi directly or as a module. Those use cases require more in-depth analysis – e.g we can perform a lot of logging of transactions (requests/responses) transparently in Okapi and thus alleviate the module from implicit logging. But this may not be powerful enough – Okapi only sees data specific to the particular request and does not see/understand the larger context of the request and the effective change to the state of the system object/entity. E.g logging a loan action may require context for what loan policy is attached to it, if the are any outstanding request or fees/fines. |
| Comment by Peter Murray [ 27/Aug/18 ] |
|
Work being covered elsewhere. |