Standard Enterprise Services

[former_member184154]

Hi everybody,

I am approaching an E-SOA implementation.

Before starting to write web services in the wrong way, I preferred having a look at what SAP was doing, so I installed ECC-SE (Service Enablement) on an ECC 6.0 system.

At first, I was proposing an inside-out approach for custom services, following this path:

- build a solid remote enabled function module

- create a custom Business Object (in trx SWO1) and link the FM to the BO as an API method

- create a web service definition on the BO for its methods

- release the web service and bla bla bla

Then I had a look at standard services coming with the ECC-SE addon, and quickly realized that they're all (most of them at least) developed starting from an XI messaf interface, that is with an outside in approach.

The question is: what would you recommend? Is there a special reason for SAP building Enteprise Services this way, and not <i>my way</i>? (For instance, to have a common repository for data types...?)

Thank you very much.

Regards,

Alex

[Former Member]

hi alessandro,

I personally suspect that to be an IP related issue primarily. at SAP they seem to sit back and define lots of service interfaces and claim IP rights on it. only later (based on actual demand?) they really implement those services.

some in this industry seem to consider the IP on an interface definition the real value and the (proper) implementation only a commoditiy. this is a strong driver for the outside-in-approach.

for those of us facin actual landscapes rather than generic ones, the inside-out-apporach seems equally appropriate to me. at least as long as we don't want to become 'general audience service providers'.

just my 2 cents,

anton

[former_member184154]

Hi Anton,

Thanks for your really appreciated "two cents"

In fact, after posting my thread here, I thought hardly about it, and found some <b>pros and cons for the outside-in approach</b>:

- by defining our own SWCV, we can set a dependency from SAP standard one(s), and <i>use standard data types in building custom one</i>. Do you think this is a good idea actually?

- placing the interface design on XI Integration Repository, we're somehow compelled <i>to create element and structures that will better resemble what is expected in a WSDL</i>... Abaper in fact (no offense for Abaper! I'm one of them as well) are usually still DDIC-minded, with those ugly uppercase fieldnames, so that it's hard with inside-out approach to have kina good data definitions...

- <i>data definitions are defined centrally</i> in Integration Repository, and basic data types can be reused in a number of scenarios, not only for SAP centric services.

- on the other hand, the outside-in approach brings with himself a XI embedded limitation: <i>any WSDL will have exactly one and only one operation</i>, which is not abig deal, you'd say, but from my standpoint it's really annoying, and very little SOA compliant.

<b>Once again, BPX's, you're welcome to express your valuable opinion.</b>

Cheers,

Alex

[Former Member]

hi alessandro,

let my call your ponints a)b)c)d).

ad a)

in theory this is certainly a good idea.

in practice i think of the ddic. how many 'duplicate' domains and datatypes are although existing ones could be reused? lots. and why? 1) who has the time to always browse through all existing types to find one to re-use? 2) who trusts a dataype 'belonging to someone else's domain/ownership'? what if they change it without notifying me?

ad b)

true. for me this is the best arguments of those you listed. there are options though to map 'internal interface names' to external ones. but it's more than only ugly parameter names. the outside-in-approach allows to free the service from SAP specific semantics making it more usable/understandable for non-SAP environments.

ad c) see a)

ad d)

I don't konw that. is that true? this would really be a severe limitation. but I think you can import WSDLs into XI with more than 1 operation so I suppose there must be a possibility to also create such services.

anton