Web-services granularity with SAP project ?

Question

In a project that comes as a third-app on top of SAP to extent its functionality thru SOAP web-services, I am wondering how should be defined the web-services themselves ; should we implement dozen of web-services that achieve simple & atomic actions, or very few web-services that takes a bunch of parameters and does all the thing.

I am interested in feedback & suggestions considering :
- workload on the SAP netweaver layer (amount of concurrent web services)
- third app maintenance
- SAP web-services maintenance
- network load (considering SOAP enveloppes & http requests)
- any other consideration I may not have thought of

Thanks

OB.

Answer 1

Generalising away from SAP, my first thought when defining a Web Service interface is that coarse-grained services tend to be more appropriate than busy fine-grained services.

This is firstly because the overhead of each call is comparatively large, so fewer round-trips tend to be preferable. (Eg. GetName, GetAddress, GetPhoneNumber versus GetPersonInfo)

Second, if there is logic we want the service to own it. We don't want each client to need to know the order in which to call fine-grained methods. Otherwise we end up duplicating logic in each client.

I have an article here which elaborates on issues such as this.

Answer 2

As far as the workload on the SAP netweaver layer is a concern. It shouldn't be. The sap abap application server is as mature platform as you will encounter. It scales wonderfully and can take any load, as long as it got something in the cpu's ( which he uses efficiently).

So the question is more of network overhead and maintenance. Like djna I to believe that coarse-grained is the way to go. But there is nothing specifically sap'y about it.

Answer 3

I would just follow the road, that SAP paved: starting with creating CRUD like fine grained services. When you browse the SAP Enterprise Services Wiki, you will find that most services provided by SAP are fine grained.

Assuming that you are currently in the first iteration of your service API, it's about sure, that you won't get a high-level API correct on the first try, but instead would have to extend it for more and more special cases in the future anyway. So why not start with a fine grained API and provide a higher-level API based on real world experience later - again as SAP did with the composition services.

Sure, performance is a consideration, but as written above: the enterprise services infrastructure is a shell for the time-tested ABAP engine and this one is quick.