CPO NBWS

[Michael Whiteley]

NBWS calls can take 30 seconds or more to complete, from the simplest GetProcessInstanceStatuses to the more complex create target types. I have the webservice running on a lightly loaded 8core 12GB system that's on the same system as the CPO Server and DB - I know that's a no-no, but 30 seconds seems on the high side. Even on a real 3-system implementation, 20+ seconds is observed on a good day.

Are there any guidelines to speeding-up NBWS calls? BTW, I'm using Digest on 61527, if that makes any difference

Thanks,

Mike

Sent from Cisco Technical Support iPad App

[Shaun Roberts]

nothing that I'm aware of, but you might want to ping dev with this. I tend to use BASIC auth.

[rruckley]

Mike,
Greetings from Australia!

Are you doing these calls using the WSDL as I think pulling the WSDL down takes a while. I've noticed that even the Service link just posts direct to then NBWS as its much faster. I've noticed this in my orchestration also. The NBWS can get quite large.

Thoughts?

Sent from Cisco Technical Support iPad App

[Shaun Roberts]

It is much faster to use the web http request and make a direct call into the NBWS than using the web execute activity and putting in this WSDL. This is because the web execute activity has to work with the WSDL for each call, although having the WSDL and such is much more user friendly.

I switch out the activities in one of my processes from WSDL based to SOAP API based in my calls back into CPO and I shaved about 28 seconds off of each call which is huge when making many calls

[Michael Whiteley]

Hi Ryan - good to hear from you. Yes - I've since switched to rest API. For integrations to some other software that do not support rest, however, I've sometimes written my own SOAP client and this reduced time down to 270 MS in one case! There is a TAC case open to solve the costly WSDL fetch

With Regards
Mike

[Von Jones]

Can you post the TAC case number?

[Michael Whiteley]

SR 623015817. Bug CSCtx35553 (related)

[Svetlana Kryukova · Accepted solution]

I would like to correct a few "misstatements" that were made in the course of this thread.

1) Orchestrator's Northbound Web Service is a SOAP web service. It is not REST. There are two methods of calling a SOAP Web Service from within a workflow: Web Service Execute and Web HTTP Request  activities. The method used to call the web service does not change its nature. Only Web HTTP Request activity can be used for calling REST Web Services.

2) Web Service Execute activity has a friendlier interface to work with (no need to go down to the level of formatting the XML request), but has a lot of overhead. The activity pulls down the WSDL (which could be large). It also "compiles" on the fly some code to make the actual web service calls. Thus the overhead. The was some work done to cache the WSDL and generated code to reduce the overhead.

3) There is no need to write your own SOAP web service to speed up the execution. You should simply use Web HTTP Request activity if speed is more important than "user friendliness".

[rruckley]

Svetlana,

It always helps to be clear about terms. I think perhaps the WSDL can get large and thus take a while to pull down and parse. I have done integration with other products, e.g. HP Service Manager whos WSDL is not only large but dynamically generated and thus can take a while (> 30sec) to use with a web service call.

I think Mike was stating he has written a SOAP server for a service that doesn't have one. I've also done this for my security system so I can query it using SOAP calls. It makes integration much easier.

Ryan