Trouble activating web service after interface change

[former_member344006]

Guru's,

After adding a field to a web service I now get the error 'Invalid parameter value or combination' upon activating the Service Definition in SE80 (see my steps below).  The problem comes in step 4 or 5, depending on how you view when the object should activate.

I've changed web service interfaces before, including after we upgraded to ECC 6.0, and have even changed this specific Service Definition before.  This web service existed before we upgraded to ECC 6.0.  The only thing I see that has changed since my last successful efforts has been that a new web service was created, and so we had to get SOAMANAGER up and running to get the new web service out the door.  Basis has told me that they did not 'convert' the old web services to SAOMANAGER, and so we were hoping to continue to use WSADMIN & WSCONFIG with them.  Does this error that I'm now getting mean that I have to convert this web service to use SOAMANAGER, and if so, how would I do that?

1) SE37 add a field to the interface and activate the function module

2) SE80 pull up Service Definition under Enterprise Services, and in change mode click syntax check

3) After getting popup that 'Service Definition is inconsistent, should it be adjusted' I click yes, and get 'Check successful' message

4) Clicking Activate, I get a green light telling me that the Service Definition was 'saved', but it still shows as 'Inactive'

5) Clicking Activate again, I now get the error 'Invalid parameter value or combination'

I appreciate any help that you can offer - thanks!

[former_member344006]

Answers to my question....

1)  I was able to find a sandbox environment where the SOAMANAGER had yet to be installed, and there I was able to change and activate my web service just like in the good old days (prior to SOAMANAGER).  So yes, this error is related to SOAMANAGER.

2)  Moving back to the development box where SOAMANAGER is installed, I tried Simulation Only mode in WSMIGRATE on the web service in question, and it came up with an error; Endpoint type is not unique.  This leads me to believe that I can't migrate the web service into SOAMANAGER.

3) I'm off to delete the 'old style' current web service configuration, which can be done, it says, in WSMIGRATE, and recreate it new in SOAMANAGER.

Thanks

[former_member344006]

Other notes:

1) I used WSMIRGRATE to 'delete' my old style service definition.  This said it was successful.

2) I went into my function module and started to create a new web service with the same name as the old style, but was told that it already existed.

3) In SE80 in renamed the old style service definition.

4) Now I was able to successfully complete step 2.

Aside from time lost, the only lingering effect is that the renamed old style service definition still appears in SE80.

[former_member344006]

UPDATE AND FINAL ANSWER:

While changing the I/F on another web service that was created in ECC5.0 and is now being modified in ECC6.0 I ran into the same problem, but had time to wait for OSS to handle it.  Here are the steps that I went through with OSS that finally resolved the error mentioned above:
1) per OSS: Implement the note 1649307.Apply the reports WS_MANUAL_WEBI_AFTER_IMPORT and WEBI_CHECK_REPAIR to repair the service definition.

(my notes: the service definition still wouldn't activate)

2) per OSS: the problem is fixed with the attached note 1677075. Please implement the note and retest.

(my notes: the service definition still wouldn't activate)

3) per OSS: Due to the missing note, the service definition

ZEC_VI_TAX_JURCODE_DETERMINE was inconsistent. We have correct the

inconstency and now it is possible to change and active the service definition again.

( my notes: SAP got into the system and manually fixed the service definition)

As follow-up, I asked OSS these questions:

1) With these notes installed will future changes to our web services created in

ECC 5.0 act normally now that we're in ECC6.0, or will we have to run WS_MANUAL_WEBI_AFTER_IMPORT after a change?

2) Do these notes need to

migrate to our Production environment to ensure the Service Definition

transports properly?

3) When should our web services be migrated into

SOAMANAGER? As I mentioned in my initial verbiage of this note, we'd had this

issue before, and I got around it by renaming it and moving it to SOAMANAGER.

Now that zec_vi_tax_jurcode_determine generates I don't appear to have to make

use of SOAMANAGER, so is SOAMANAGER only for any new web services we create?

And here are their answers:

1. No, it is not needed to run the report after a change.

2. Yes, you should also implement the note in the production environment.

3.We recommend you to use transaction SOAMANAGER from 7.00 SP14 onwards

as described in the SAP Note 1120273.