Your spec isn't generic. The parser you use shouldn't be either. Custom fields, groups and messages are supported out of the box.
Sensitive production data? No problem. Your logs never leave your machine.
| Time | Sender | Target | Message Type | Summary |
|---|---|---|---|---|
| 23:24:06 | CLIENT | FIXDEV | Logon | |
| 23:24:06 | FIXDEV | CLIENT | Logon | |
| 23:24:37 | FIXDEV | CLIENT | Heartbeat | |
| 23:24:37 | CLIENT | FIXDEV | Heartbeat | |
| 23:24:42 | FIXDEV | CLIENT | New Order Single | |
| 23:24:42 | CLIENT | FIXDEV | Execution Report | |
| 23:24:42 | CLIENT | FIXDEV | Execution Report | |
| 23:24:55 | FIXDEV | CLIENT | New Order Single | |
| 23:24:55 | CLIENT | FIXDEV | Execution Report | |
| 23:24:55 | CLIENT | FIXDEV | Execution Report | |
| 23:25:12 | FIXDEV | CLIENT | New Order Single | |
| 23:25:12 | CLIENT | FIXDEV | Execution Report | |
| 23:25:16 | FIXDEV | CLIENT | Order Cancel Request | |
| 23:25:16 | CLIENT | FIXDEV | Reject | Unsupported message type |
| 23:25:25 | FIXDEV | CLIENT | Order Cancel Request | |
| 23:25:25 | CLIENT | FIXDEV | Reject | Unsupported message type |
This message requests a Heartbeat <35=0> from the opposing application, to verify it is still responsive. The other application responds with a Heartbeat <35=0> echoing back the given TestReqID (112).
TestReqID (112) ensures that the opposite application has generated the Heartbeat as the result of a specific Test Request and not a normal timeout. The opposite application includes the TestReqID in the resulting Heartbeat. Any string can be used as the TestReqID, but uniqueness is preferable for debugging purposes. Timestamps, sequences, or UUIDs are sensible choices.
| Tag | Name | Type | Required | Description |
|---|---|---|---|---|
| Component | ||||
TestReqID | ||||
| Component |
Import your existing spec from common XML formats, including QuickFIX XML, or create one from scratch
