Handling Multiple Service Responses

Hi,

I am seeking some opinions about how others handle this situation :-

A service exposes an operation (lets assume it is implemented as a web
service using SAP).

A request is sent to the service and the service may respond with :-

a. A payload representing the expected successful outcome to the request
b. of a NUMBER of unsuccessful response types (note: I am not
necessarily saying these are errors per se)
c. A SAP Fault indicating some sort of technical failure in calling the
service

It is (b) that I am uncertain about.

(i) I want to make it easy for the calling client to discern whether they
have a success response, or a non success repsonse (the technical error is
easy).

(ii) The calling client may need to take different actions based on which
one of the many different UNsuccessful response messages is returned.

For (i) I thought that, rather than returning a different message structure
for each different response type (b) I would model this as a common
'business response' structure which [say] includes a business response code
that the caller can use to identify which of the 'published' non success
outcomes has actually occurred (I am assuming here that these type of
responses don't include any useful data other than the response code that
the client needs).

This would have the advantage that the client only needs to understand 3
types of response for this operation, the success response, the non success
response and the SAP Fault (rather than 'n' non-success responses)

I considered just using 2 response types, success and SAP Fault, but I
think it might be better to reserve SAP Faults to non business messages
that we don't really want a caller to have to be concerned with (other than
the fact that the invocation failed).

I have to say I'm pretty uncertain about this on the one hand I feel like
creating specific message types for all possible responses that the service
*could* return, but on the other, this seems like it might just make life
more difficult for the caller ?? The determination of what is a
business 'error' *may* be in the context of the caller even where the
service asserts an error (i.e. the caller may choose to consume and
continue).

Has anyone else faced this predicament or do you have a view about the
'straw man' approach outlined above or a better alternative ?

Cheers

Fraser.