To CLT or not to CLT

System

Of my last three projects the first two implemented most of the customizations in C#/.NET and the last implemented customizations in Java. For various reasons the CLTs were used as the API to TeamSite in almost all cases. After the .NET projects went into production there were performance problems. The first customer was able to throw hardware at the problem and actually got Interwoven to make some of the CLT functionality available through a DLL. The second customer does not have the budget for hardware or this DLL. The third customer (Java) is in production and does not have performance problems.

Interwoven told the second customer that the performance problems are a result of using the Command Line Tools and that they should convert to using the SOAP API. Personally I don't see how using the CLTs could be a problem (though I know it's not the most efficient way to manage processes) since the CLTs have been used extensively on all Interwoven implementations I've been involved with, as they were the only APIs before OpenAPI and the SOAP API. I also understand that some OpenAPI calls (such as that which creates a job, which is the specific function that the second customer has the most performance problems with) actually call the CLTs, and I would assume that the SOAP API calls OpenAPI which calls the CLTs - meaning that SOAP would just add overhead (and might obscure error messages returned by the CLTs as described in previous posts). Finally I doubt many Perl implementations are using OpenAPI or SOAP. Aren't we all using the CLTs?

How many implementations are using interfaces other than the CLTs? I am less interested in OpenAPI because it still requires a username/password or session ID for most functions and this is not available to workflow externaltask processes. If the same is required for the SOAP API calls I don't think that would have much value either.

Thanks in advance.