Validate inbound messages

[onthebreeze]

As a tester that is sending a message FROM some external system (eg my own system under test) TO my virtual ledger account then

• I want the message to be validated in accordance with the BILL spec (structure and codes and rules).
• I want to be able to click on a "validation" link and see the detailed error message.

[monkeypants]

Is it the case that the "validation" link is a warning symbol, and only present if BILL spec validation fails (otherwise different symbol that's not a link?)

[onthebreeze]

Hmm - that question makes me realize that theee a state missing on the BILL lifecycle. There needs to be a transition from "created" to "invalid". Because the receiver TAP will confirm receipt but only the ledger can confirm validity. So that means that the virtual ledger should

• Rerun a "received" document response for a valid document (and link to it)
• return an "invalid" document response for an invalid document (and link to it)

[monkeypants]

and do we have "error" and "warning" both? I mean

• received
• received with warnings
  *received with error (basically rejected)

While this is payload semantics and TAP is envelope semantics, FWIW the TAP will reject (HTTP POST will not get a 2xx response) if the submission is invalid submissions (schema validation etc). However, there are asynchronous processes, such as signature checking, that can also result in non-delivery despite the HTTP 200 on POST. In this case, we report the appropriate message status if they ask about the message status (callback method TODO, assumes sender polls status).

[onthebreeze]

TAP would reject for a schema validation failure of the envelope.

But I'm talking about schema validation of the document content. Which would require a business response document from the ledger, not a http error code from the TAP.

[monkeypants]

yes I know that

While this is payload semantics and TAP is envelope semantics, FWIW...

I was just pointing out how we were doing things on the next onion ring outside this one, because it might be an opportunity for consistency.

For example, should the buyer ledger automatically do stuff (complain to seller) if there are errors in the doc, or wait for the buyer talk to the seller about it in person?

[onthebreeze]

I think it's up to the buyer ledger to decide how strict it wants to be with document validation. But you'd think there would be cases where it simply can't process and so needs to reject

Our virtual ledger should be strict and should reject anything that fails structure or codes or rules

[onthebreeze]

Because it's a testing tool - and so strict drives better quality in the community

However if I were a proper production ledger I'd try not to reject unless I had to.

[monkeypants]

is there a "you sent me a technically invalid invoice" message in the BILL spec?