TM Forum Community

Hello,

If there is a TMF API (say TMF622) which is used for different consumers and each consumer expects different error messages for the same functionality, can someone advice on what the best way is for error handling?

For now, we have these 2 options on mind:

1. Hard coding the different error messages per consumer
2. Creating a reference data, to differentiate the error messages per consumer, even if there is no reuse (today).

Thanks in advance!

#OpenDigitalArchitecture

------------------------------
Manaswini Jayaraman
Proximus SA
------------------------------

Hi Manaswini

I would posit that this is not a recommended approach in integration architecture. Basically you end up creating a very strong dependency between the provider and the consumer.

In my view, the provider should be able to advertise all the different error conditions that can happen as a result of (say) POSTing a ProductOrder. It's now up to each consumer to decide what it will do with errors that are returned.

Hope it helps

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------

Which "error messages" are you referring to?  You should not change the HTTP Status Code (e.g. 404).

TMF630 v4.2.0 section 3.4 describes User, Application and Extended Error Codes which are provided as a JSON object in the body of the response:

{
    "code": 
    "reason": 
    "message": 
    "status":  
    "reference": 
    "@type": 
    "@schemaLocation": 
}

You could tailor this however the question becomes: based on what?  If your server responds differently from request to request it breaks determinism.  The proper way to handle that is to use Media Types. TMF630 specifies application/json however you could use Content Negotiation to add additional types.  We do this at SigScale to allow clients to request IETF Problem Details (RFC7807) encoding, as used by 3GPP and ETSI (see AP-2628).  The client would add the media type (application/problem+json) to it's accepted media types in the request:

POST /productOrder
Content-Type: application/json
Accept: application/problem+json, application/json

This tells the server that a response body may contain the IETF Problem details JSON object or the TMF Forum JSON object. The server response shall indicate which in the Content-Type header:

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

You could use your own media type(s) (e.g. application/vnd.acme.problem) or you could extend the TMF type with a parameter (e.g. schema=acmeError) (although RFC4627 doesn't specify any, so this is an invention):

POST /productOrder
Content-Type: application/json
Accept: application/json;schema=AcmeError

You could then extend the JSON Schema (Common/Error.schema.json) polymorphically with whatever extra attributes you wanted:

{
    "@type": "AcmeError",
    "@schemaLocation": "/schema/AcmeError.schema.json",
     "acmeCode": 42,
    ...
}

If you use a polymorphic extension you wouldn't need to use content negotiation as all as long at it's OK to send the same extended response to all clients.  Clients which don't understand AcmeError should ignore the extra attributes, however they may request exactly the type (i.e. AcmeError) they prefer to accept.

------------------------------
Vance Shipley
SigScale
------------------------------