ATP - Create Customer Requirement

[Former Member]

Hello,

I am a little bit overwhelmed by that about 60-page long WSDL file I found for the web service "create customer requirement" in the ATP web service bundle. (<a href="http://erp.esworkplace.sap.com/socoview(bD1kZSZjPTgwMCZkPW1pbg==)/smdisplay.asp?id=8F03010018A911DB8CE20007E9102256&fragID=&packageid=DBBB6D8AA3B382F191E0000F20F64781&iv=">interface description</a>)

Does anybody have knowledge or examples on how to create a simple requirement? 1 product, 1 customer, 1 location; so say I am looking for a <i>Hello World</i> for this service.

Thanks

Stefan

[Former Member]

Hi Stefan,

unfortuntely I don't have a HelloWorld for this service.

But I would bet a lot of money on my guess, that this monster of a service does not represent the webservice future.

I think in a large Corporation it often occurs that some people (in this case those who give birth to such dinosaurs) are not aware of the strategic objections others in the same company issue. maybe they also spend so much time in service definition groups and similar forums that the outcome is a compromise to the largest extent anyone can think of.

I mean, elswhere in this community they talk of the appraised BPX and how easily she will compose processes or at least sub-processes with tools like visual composer by simply combining existing services of various origins and so on...

Does anyone really think that this BPX will master a monster like the example given? Maybe, but then you'll need one BPX per such service. But I think - no way.

Additionally, I don't think that any real world operation is really so excessive than the one this interface allows to perform. To me this is like if you want to cook some nice spaghetti and in preparation buy all goods available at the next supermarket, transport them home and only later decide that out of all that stuff you need water, oil, pasta, tomato sauce, minced meat, some spices, Parmesan cheese and a nice bottle of wine.

And what about all those coded values not available in the WSDL (restricition base, enumeration) but only some accompanying documentation? Do they expect a service consumer to really read trillions of pages of (not fully available?) documentation?

Maybe this service is useful for some closely related SAP systems to exchange maximum information, but I don't see a real usage between different systems of maybe not so related parties.

In reality, those monsters will be cut down to usable services (variants) resembling only partial functionality with the monsters only being a backup for certain circumstances and

crazy geeks.

My 2.4 cents,

anton

[former_member583013]

Stefan and Anton,

Unfortunately I don't have a "Hello World" for that service either, but Stefan's question and Anton's comment bring up a topic I find interesting in general: What kind of services can you expect from a packaged application vendor like SAP?

Contrary to popular belief in the early Web services days, I don't think it is possible to design good services without knowing how they will be consumed. Of course there may be simple services where this is possible, but in general designing more complex business-relevant services will require some knowledge about how they will be used. This knowledge can include typical client use cases as well details on the client technology.

We cannot always expect the packaged application vendor to provide the exact services we need. In my mind, the real beauty of SOA is that it enables a company to decide where to standardize on best practices packaged into shrink-wrapped applications and where to invest in development of differentiating innovative applications - And keep the two nicely integrated through services.

To make this real, we will often need a middle layer between the packaged application usually providing services and the custom application usually consuming services. The middle layer takes care of turning the "monsters" into the "variants" Anton talks about. This can take the form of simplifying the semantics, reducing the number of parameters, mapping data types to ones the client understands, and so on. The famous BPX may then be able to work his/her magic on top of the simpler services exposed by the middle layer.

I will try to elaborate on these thoughts here on SDN later, including some examples where we in my current company have used purpose-specific middle layers to tie mobile applications and Yahoo widgets (requiring simple data provisioning and control services) as well as Microsoft Excel (requiring large amounts of analytical data) into our single set of back-end services.

Regards, Kaj

[Former Member]

Hello Kaj,

thanks for your thoughts on the topic.

I fully agree with your comment that customers should not expect the packaged application vendor to provide the exact services he needs. I think the customer can expect a number of good examples or templates covering a broad range of the applications' capabilities. Being prepared to the necessity to adopt nearly fitting services to one's specific needs the customer is in a good position to create a whole lot of new exciting scenarios.

But it is my strong opinion that those services delivered have to be in alignment with strategic promises of the same packaged application vendor who tells customers that SOA, composite applications, visual design and the like will help a new role - the BPX - in the enterprise to create scenarios on a more abstract level.

And I believe services like the one discussed here are counter productive to the ability to reach the promised effects.

Looking forward to your elaboration and maybe som fruitful further discussion,

anton

[Former Member]

Hi Kaj, Anton,

it is nice to get such a nice discussion on web service dinosaurs. From my point of view these service are almost as useful as having no services available consideing the almost not available documentation including examples and so on. Just imagine what it costs to have a workflow expert or programmer working one full week to figure out how those monsters work.

Anyway, beside these thoughts that need to be read by every service creator, it would still be nice to have a service representative from SAP available to give us at least a simple example on what this particular service takes in order to give satisfying results.

Cheers,

Stefan