WSADMIN Obsolete....now what?

[Former Member]

Webservices worked fine in SAP:

SE37 -> Create Service -> WSADMIN - > WSDL.

Now SAP invented this thing called SOAMANAGER. Maybe it's an architectural wonder. Maybe it makes sense. Maybe it follows every standard in the book. Too bad I just want things to actually work.

After SP14, I can't get Visual Studio 2008 to read the new WSDLs ("legacy" WSADMIN WSDLs are read just fine). Now I have a service wizard that tells me I need to run WSADMIN2. Too bad I don't have a J2EE and I don't want a J2EE server. I hate SAP Java, I think it's a piece of utter rubbish and waste of disk space.

How can I actually use webservices in SAP post SP14 in pure ABAP world? I repeat, I didn't need a J2EE server before, and I makes little sense to need one after a simple SP (not version on enhancement package upgrade). A SP should fix bugs and leave basic functionality alone. This policy of SPs containing tons of changes is ridiculous and goes against the very concept of SP.

[brad_bohn]

I'm not thoroughly convinced that you don't need a J2EE server yet. The only systems where our SOAMANAGER transaction does work at this point are the ones such as Solution Manager that have the ICM running with J2EE. On our ERP system, which is ABAP stack only and where J2EE is not installed, the ICM runs under ABAP and SOAMANAGER does not work, even though the necessary services are active in SICF. As usual, there's no definitive documentation that identifies possible issues, so I'm still investigating. Good luck.

[Former Member]

Hi,

No, SOAMANAGER is abap only.

It works perfectly on our abap only ECC6 system.

You only need a java stack if you want to use the SAP Web Service Navigator which is a Java application.

It is convenient to test abap web services but you can use any other client (like SOAPUI for example).

It's even better to convince you that the wab service is not only SAP compatible...

Regards,

Olivier

[brad_bohn]

Right, you're correct. I found the issue today after alot of digging. Our issue was that the ICM was not configured correctly. Afetr comparing the instance profile parameters for the ICM for the two systems, I found that 'icm/server_port_0' and 'icm/host_name_full' had not been specified in the non-working system that didn't have J2EE installed (they are not configured by default). Once I set those values in the instance profile and cycled the server, SOAMANAGER worked just fine. Hope this helps someone else!

[Former Member]

Hi,

AFAIK SOAMANAGER is a webdynpro ABAP application. so you don't need a J2EE server, but you need a browser. see transaction SICF for details.

Although I don't agree with your assesment of WAS Java (or "SAP Java") I too share your criticism of delivering completely new an disrupting functionality in service packs.

but actually, it's the way it is. nothing much to do about it but to learn to live with it.

anton

[Former Member]

Hi,

What is your specific problem ?

I was able with no problem to use SOAMANAGER on CRM 2007 SP 16.

I did not need a J2EE stack.

We are able to call this abap web service from a weblogic client.

I was also very surprised by the big change of configuration before and after SP14.

I think it's illogical to do half of the configuration with the sapgui and the second half with a web browser.

Talk about consistency...

I have nearly the same feelings than you for the SAP J2EE even if I don't express it so strongly !

Regards,

Olivier