Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Problems release Webservice for SOAP runtime to a non-modifiable client

Former Member
0 Kudos

Hi

I created a webservice definition ( virtual interface & all dependent objects ) in a development client ( client- A ) of a ECC5.0 instance.

Now, we have another client ( client-B ) in the same server that we want to release the webservice for SOAP runtime. ( reason is that the webservice is not available at runtime in this client-B client )

This client-B has status - non-modifiable and hence cannot use WSCONFIG --> create option to release it for runtime.

How do we release this webservice definition to client - B . I tried a SCC1 transaction on client-B pointing to the transport that contains the WS definition in client-A. I got dictionary errors indicating that the WS definition objects are all client independent.

Is there something I am missing ? Any thoughts/similar experiences shared is appreciated.

1 ACCEPTED SOLUTION

Sm1tje
Active Contributor
0 Kudos

I haven't experienced anything like it, but easiest way to solve this, is to set this client open for change.

4 REPLIES 4

Sm1tje
Active Contributor
0 Kudos

I haven't experienced anything like it, but easiest way to solve this, is to set this client open for change.

Former Member
0 Kudos

Hi

Just to clarify your answer - Do you mean to say - that the right way to release the WS for SRT - in a non-modifiable client - is to do a SCC1 from the original development client to the non-modifiable client and that worked for you always ?

Former Member
0 Kudos

Ok..we opened the client and released the webservice in the second client....

Sm1tje
Active Contributor
0 Kudos

Good to hear it worked out for you. But like I already said, I haven't experienced anything like this, but for similar problems this is exactly what we did to solve it. But you're probably right, that this is no long term solution. There should be another way of doing this, but no experience in that field expertise.