Simple API Management like restriction: Only allow e.g. 20 records per request

[JaySchwendemann]

Hi all,

we have a material availability service which we want to expose to our customers. Some customers are low profile, some customers are very important. The material availability service allows to request multiple materials per request.

Ultimately I'd like to limit the requested materials based on customer and time range to different values, e.g.

Premium Customer: 1000 Materials per day

Standard Customer: 100 Materials per day.

I think this ideal solution would best be solvable using SAPs API Management (API Management | Application Programming Interface | SAP) or similar 3rd party solutions.

However, we do not currently plan to introduce such an solution.

This leaves me with a (arguably short falling) plan: I'd at least want to restrict the numbers of materials per Request. I know this doesn't prevent the customer from issuing multiple requests. But its a start. Plus I don't want to go down the road and save metadata like how many requests a customer did to my business system to do more sophisticated checks. I think that would be overkill for this wanted "limitation" should simply guide the customer, not prevent fraudulent users from calling the service

So my concrete questions are:

1. I know I can use "count" function and an UDF to raise an error in message mapping. Would I better raise an RuntimeException or a StreamTransformationException?
2. Is there another / better way to achieve the wanted functionality given the side conditions (no saving metadata to business system, no dedicated API management solution available)

Many thanks and kind regards

Jens

[engswee · Accepted solution]

Hi Jens

The requirement for the restriction seems to fall more into "application logic" rather than "integration logic". As such I would explore if it's possible for the backend application to raise an application fault which then is propagated back to the calling system. This seems cleaner than raising a mapping exception in PI which results in a system error, and if I'm not mistaken, the full error might not be available back to the calling system (I might be wrong).

You didn't mention how the sender and receiver connectivity is going to be like, and whether async or sync - SOAP to Proxy Synchronous?

If you really want to raise the exception in UDF, both exception types should be fine.

Regards

Eng Swee

[JaySchwendemann · Accepted solution]

Hi Eng Swee, Hi all,

thanks for the valuable input. About your topics:

1. "application logic" vs "integration logic"

--> I think from an outsiders perspective this is a correct assumption. I was afraid of extending the backend application to do such checks, as they are highly dependable on the customer. When doing such checks in Mapping, I'm already "customer specific" as almost every customer needs their own mapping anyway. But It's a valid point. Will consider this

2. "system error not be available to the calling system" (maybe)

--> I'll be happy to report back, if this is the case. However, System error indeed limits error handling posibilities as there's then no way to do fault error mapping, right?

3. Sender <-> Receiver connectivity

--> Sorry for the shortcoming. It's a synchronous 3rd party Sender (SOAP) --> PI (7.4) --> ERP (APAB Proxy) scenario.

I'll first fiddle around with the UDF as this seems to be a easily applicapble withou modifying the backend application (read: the backend ERP Inbound proxy). I'll report back, if I run into problems or what the outcome was.

Many thanks so far. If there are other aspects, I should consider, I'd be happy to hear from you (Eng Swee or others)

Cheers

Jens

[JaySchwendemann · Accepted solution]

About topic 2. The error will be reported back (if your PI is setup accordingly) to receiver in such manner

So this is not ideal, but would work as a guidance for the customer.

[engswee · Accepted solution]

Thanks for updating. That's great that the calling system have access to the full error message raised.