All geek questions in one place

Granularity of web services with an SAP project?

In a project that is included as a third application on top of SAP, to expand its functionality through SOAP web services, I wonder how to define the web services themselves; we must implement dozens of web services that achieve simple and atomic actions or very few web services that take a bunch of parameters and do everything.

I'm interested in feedback and suggestions regarding:
- workload at the level of the SAP network environment (number of parallel web services)
- servicing the third application
- servicing SAP web services
- loading the network (taking into account SOAP packets and HTTP requests)
- any other a consideration that I might not have thought about

thanks

OB.

+3
source share
3 answers

In a generalization from SAP, my first thought in defining a web service interface is that coarse services are generally more appropriate than busy fine-grained services.

This is, firstly, because the overhead of each call is relatively large, so less round trips are preferable. (E.g. GetName, GetAddress, GetPhoneNumber and GetPersonInfo)

Secondly, if there is logic, we want the service to own it. We do not want each client to need to know the order in which fine-grained methods can be called up. Otherwise, we end up duplicating the logic in each client.

, .

+2

, SAP : CRUD, . SAP Enterprise Services Wiki, , , SAP, .

, API, , API , . , API API , - , SAP .

, - , , : - ABAP, .

+1

SAP . . sap abap - , . , - ( ).

, . djna, , - . .

0
source

Source: https://habr.com/ru/post/1719535/

More articles:


All Articles