VUS Design

Streams

With no specific order and dependencies, the overall VUS development effort can be categorized into multiple streams.

1. Core Logic

Approach

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 features

• Core logic design from previous plus...
• VUS Ref Id generation
  • ensuring uniqueness, durable with re-start

Concerns regarding NFR including:

• 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?

2. Event Source Adapters

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.

3. Router and Event Sink (???)

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 integrationstream.

4. Integration

Define the communication channel, queues, set up of MQ, and message types between systems. Concerned with message consumption and dispatch.

Client (i.e. SEB)

• 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

Reference data

• UAF
• Static database

Source systems / Upstream systems

• RTCR
• FX Away
• MFPS
• InfoM(?)

4. Operational Concerns

Monitoring / Alerts

• Defining alertable events
  • Need to determine the criteria for raising alerts
• Related to UI

Reporting (only in relation to VUS messages)

• Identify the requirement and source system(s)

UI

• Need further analysis on the requirements
• ACL requirements
  • Role based?

---

Core

• Generation of VUS ref id and mapping from tx id(s)
• Creation and dispatch VUS messages to SEB

Adapters

---

How to handle things?

• Message loss?
• Exception