Sizing considerations.

[Howsie]

I'm looking for some guidance regarding the most appropriate method of interfacing with external applications/suppliers. To cut a very long story short I'm looking at volumes of approx 1 TX per second.

I'm torn between using WSDL/Connect.IT or SCAuto. I have used SCAuto in the past with great success but the client is keen on using WSDL.

I have raised this with HP and they couldn't provide any guidance and only said that WSDL hasn't been load tested...

Your perspective is welcome.

[mateuszk]

Hi,

one advantage of using WS would be the possibility of using loadBalancer for the listener.
Haven't tested it yet (I guess I'm on the same level as HP :-) but I see no reason for this not to work.
Since WS uses the same interface as other SC clients ... need to test it one day.

Having said that, I don't really see ConnectIt as the most reliable/performing tool I can think of when it comes to WebServices. It's a great tool though, easy to implement etc.

For me, synchronized request/reply scenario is the main cause for choosing WebServices but with your setup I don't really see this advantage.
Unless you're using some combination of WS listener ... naaa ... still not making sense.

[harn145]

There are performance metrics for SM7.0 WS. You might want to push a little harder with HP.

[bodybuzz]

OK,i have some insight on this subject.

Our company has all incident and problem management through ServiceCenter 6.2 except for one piece: the help desk function is outsourced to another company who take interactions in a remedy based system. A simple data flow is:

- Help Desk associate creates interaction in Remedy

-Remedy writes XML file to sFTP server

- C# interface application processes XML files into ServiceCenter through WSDL

- Response of successful incident creation pushed to remedy through BMC Remedy API

We have stress tested this setup on our UAT environment and it runs at maximum 2.4 / second.

We originally used SCAuto and found that was not able to run fast enough and was not scalable. I am able to run multiple middle-tier systems each with the interface application running on each to spread the flow out and speed this up even further.

I would be happy to discuss further..

/.D

[mateuszk]

We have stress tested this setup on our UAT environment and it runs at maximum 2.4 / second.

I say! This is a great result (not joking).

What happens in your scenario when there's an "incoming" queue forming?
Do you process all of the load synchronously?
Did you try measuring the time of opening every consecutive record in such case (is it constant)?

Sorry for the questions, just surprised by the results.

[bodybuzz]

As yet, our production environment has never hit a point where there was a queue of >3 creates/updates pending and that is always caused the 10 second polling cycle by Remedy and not by the inability of the interface to keep up.

As it is coded right now, it is set to process the files in order that they are received.

We have a new design that has not yet been implemented that will have remedy identify the line of business in the file name and then separate processes will run the interface for each LOB. From the initial tests that we have run, there is no (or at least negligible) performance loss with 2 WSDL interfaces running against the same server.

That being said, we are running SC on some serious hardware.

App Server: HP DL585 G5 (4x Quad Core CPU w/ 8 GB RAM)
Database server: Sun E25K Zone (8 CPU and 16 GB RAM assigned tothe Domain)

This eliminates any memory or CPU bottleknecks.

Happy to discuss further..

.D

[mateuszk]

That being said, we are running SC on some serious hardware.

App Server: HP DL585 G5 (4x Quad Core CPU w/ 8 GB RAM)
Database server: Sun E25K Zone (8 CPU and 16 GB RAM assigned tothe Domain)

This eliminates any memory or CPU bottleknecks.

... but does not eliminate the design flaws that come with java (and SC :-).
A colleague of mine just hit some problems with memory management in java,
no way to go higher than 4Gb.

... but that's a completely different topic.

[Artur]

... but does not eliminate the design flaws that come with java (and SC :-).
A colleague of mine just hit some problems with memory management in java,
no way to go higher than 4Gb.

... but that's a completely different topic.

Can you explain it more?

regards
Artur

[Howsie]

There are performance metrics for SM7.0 WS. You might want to push a little harder with HP.

Interesting. Is there anything specifically I should mention when I speak to HP because I'm told there is nothing.

[Howsie]

OK,i have some insight on this subject.

Our company has all incident and problem management through ServiceCenter 6.2 except for one piece: the help desk function is outsourced to another company who take interactions in a remedy based system. A simple data flow is:

- Help Desk associate creates interaction in Remedy

-Remedy writes XML file to sFTP server

- C# interface application processes XML files into ServiceCenter through WSDL

- Response of successful incident creation pushed to remedy through BMC Remedy API

We have stress tested this setup on our UAT environment and it runs at maximum 2.4 / second.

We originally used SCAuto and found that was not able to run fast enough and was not scalable. I am able to run multiple middle-tier systems each with the interface application running on each to spread the flow out and speed this up even further.

I would be happy to discuss further..

/.D

Very interesting. Thanks for sharing! I think I'll pursue this a little further and try a little load testing.

Cheers.

PS. I've managed to scale SCAuto to huge volumes (+10 a second) in the past and I'm surprised it didn't scale for you.