-
Notifications
You must be signed in to change notification settings - Fork 0
VUS Design
With no specific order or dependencies, the overall VUS development effort can be broadly categorized into multiple streams.
Further breakdown by messages
- VUS 1, 2 or .. 7
Or breakdown by type
- Trade transactions
- MF trade transactions
- Corporate action transactions
Capture design approach for each breakdown and success criteria?
- Core logic design from previous plus...
- VUS Ref Id generation
- ensuring uniqueness, durable with re-start
- reliability
- redundancy
- durable message
- system recovery
- capacity
- scalability - both horizontal and vertical
- on which component? core only?
- performance
- what, where, how and when to measure?
- establish benchmark?
Need to filter and/or transform each input data and supply that to the Core system. Preliminary level of validation on the received data/message may also be needed. And the rule to handle those validation failures. A general approach would be to direct the message to a separate queue for further assessment and analysis.
The source system involved are:
- RTCR
- FX Away
- MFPS
- InfoM(?) - depends on VUS 5 handling
For each system identified, (may) need an adapter (or wraper?) with filter/transformer. The actual integration with respective systems are the concern of the integration stream.
There is one event sink which is to direct the output message to the client. When there's only one client the need for having the sink concept may be an overkill but when there're multiple clients the logic of determining who to send the message/data to (i.e. routing) becomes non-trivial.
Is this really needed? To have define a distinct sink vs. having it defined within the core system?
One of the additional responsibility here is the message transformation to the desired format according to the client's specification. The idea is the same message can be transformed and represented as an XML document or JSON etc.
In addition to the message format, the protocol and the transport with which the message is delivered may differ depending on the recipient. The specifics on these concerns however is managed by the integration stream.
Q: Two options, 1) Transform then Route or 2) Route then Transform. Not sure which makes more sense atm.
Define the communication channel, queues, set up of MQ, and message types between systems. Concerned with message consumption and dispatch.
- Message transformation (is this really the concern of the integration layer? or should it be moved out/up to adapter?)
- Defining the connectivity between VUS and the client
- Design of Reply/Response (or Ack/Nack) paradigm
- Consideration for durable messages and its implementation detail
- Handling dead-letter queue
- Concerned with system re-start
- UAF
- Static database
- RTCR
- FX Away
- MFPS
- InfoM(?)
General question on this stream is shouldn't this concern be handled consistently and possibly with one solution/system for all P6 projects? If every sub-projects implement its own UI and monitoring solution in a disparate manner, there will be no consistency in its functionality and operations, resulting in mixture of procedures for the operator.
Instead, if the operational concerns are addressed as a separate sub-project whereby it defines a standard approach on how the errors are reported and alerts are raised etc (along with audit and logs), the other sub-projects (like VUS) can conform to it but it need not implement its own UI for it. (and managing users etc)
- Need more detailed requirements
- Defining alertable events
- Need to determine the criteria for raising alerts
- Related to UI
- Identify the requirement and source system(s)
- What are the requirements?
- ACL requirements
- Role based?
- Handling message loss?
- Exceptions?