To CLT or not to CLT

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.

Find more posts tagged with

Comments

Johnny

I dont have much to add here, but I am certainly interested to hear more.

As far as i have seen, just about all of the PERL modules do call CLTs to perform their actions. I guess its the easiest way to make them portable between the two platforms. There could be some that dont.

John Cuiuli
Sydney, Australia

Migrateduser

Hey, since it was Interwoven that said the .NET API I developed was **** because it used the CLTs, it would be nice if someone from Interwoven could respond to this post.

james1

Most Perl modules we ship *do* use CLTs.

Most OpenAPI functionality does *not* use CLTs. In fact, I cannot think of any OpenAPI method that uses a CLT.

Specifically, the method for creating a new job from an XML job specification does *not* use "iwjobc" or any other CLT.

In OpenAPI, there is a way to initiate a session as the current user owning the JVM process without knowing that user's password. See "IWAccessorAuthenticationByFile" for more.

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

Great, maybe you can answer a question in this thread then: http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_OPENAPI&Number=14792&page=&view=&sb=&o=&vc=1

"Is OpenAPI calling iwjobc or using some other interface? What is that interface written in?"

Also can you tell me how to "generate a particular temp file with the desired user's OS credentials" on Windows? The process needing to create the file would be running as SYSTEM in a JVM on the local TeamSite server (externaltask command line).

Also, wouldn't performance be worse (from Perl or .NET) if instead of calling the CLT the code created a temp file and spawned a JVM to call OpenAPI (spawning a JVM seems much more expensive than calling a CLT)? and do you know if I can use this temp file method to authenticate with the SOAP API or do I not need to authenticate when using SOAP? looking at http://support.interwoven.com/library/manuals/teamportal/html/cs.110.ecis.htm (which I am not sure is the most recent) under services/session management it seems that the only way to create a session is with a username and password, and that session ID is required for subsequent transactions.

Thanks,

-John

Edited by john on 07/21/03 04:55 PM (server time).

Migrateduser

Actually we are not all using CLTs. Neither OpenAPI or Content Services (our SOAP interface) uses or calls CLTs underneath. All of OpenAPI, CS and the CLTs themselves call into the TeamSite server using an interface called SCIFACE.

OpenAPI and CS are more efficient than CLTs in that in typical use cases for these APIs, there is not a requirement to start-up/shutdown the related process that does the work, as with CLTs. Finally, given that we have a SOAP interface, you can directly create any binding from our WSDL (Web Services Definition Language) file to any language supported by most WSDL compilers -- these typically include Java, C# and even Perl.

As per the question about our apis being available for workflow external tasks, there is currently a project underway that will rectify this missing feature. A feature will be added into Content Services and workflow to make this possible in a future release.

Migrateduser

Thanks!

Until this next release though, is it possible to call the SCIFACE API from .NET using COM Interop or something?

Also on the SOAP, do I need to authenticate with a username and password, or how?

-John

Edited by john on 07/24/03 12:17 PM (server time).

Migrateduser

No. SCIFACE is not available externally. You could put a COM wrapper around our Java OpenAPI if you have a .NET app you're integrating with or use our upcoming CS 2.0 web services API.

For SOAP authentication, as of now yes. But this is the whole area we're looking at in terms of single sign-on.

Migrateduser

Thanks.

For the short-term what does Interwoven recommend for those customers who are experiencing performance problems that Interwoven attributes to use of the command line tools, assuming that passing a username and password to SOAP and/or OpenAPI would not be acceptable and hardware upgrades are not available? There was mention on this thread of using a file created with the credentials of a specific user to connect with OpenAPI functionality but there was no response on how to create such a file (running in a .NET or Java process as SYSTEM on Windows as part of an ExternalTask command line invocation).

Personally I don't see how invoking a CLT could be the significant performance issue. Although spawning a process is relatively expensive my assumption that it would not be as expensive as the processing that occurs after the process is created. For instance retrieving workflow XML. This can have a significant performance impact on the UI, especially if the user repeatedly refreshes, and this should not be using the CLTs. Nor could this explain why customers who implement customizations in .NET have performance issues but those that implement in Java do not seem to (unless they spawn processes differently?). There may be ways to reduce the number of CLT calls but with the existing APIs I don't see how they can be eliminated without compromising security.

Could the DLL created for one of the .NET customers (containing SCIFACE API?) be provided to other customers as an interim solution?

Migrateduser

I just want to bring these remaining open questions to the surface again.

Would it be possible for Interwoven to distribute a DLL that would provide customers running on Windows access to the SCIFACE API?

How many implementations are using interfaces other than the CLTs?

In the current release, what does Interwoven recommend customers (experiencing performance issues purportedly related to CLT usage) use to replace the CLT calls without passing a username and password?

How can an ExternalTask process running in a JVM or .NET process on a Windows TeamSite server create a file with the credentials of a specific user for use by OpenAPI IWAccessorAuthenticationByFile?

Thanks again,

-John

james1

> "Is OpenAPI calling iwjobc or using some other interface? What
> is that interface written in?"

OpenAPI does not directly invoke iwjobc. OpenAPI uses the same interface that iwjobc uses. That interface is not open to customers and partners. Instead, OpenAPI and Content Services are open to customers and partners.

> Also can you tell me how to "generate a particular temp file
> with the desired user's OS credentials" on Windows?
> The process needing to create the file would be running
> as SYSTEM in a JVM on the local TeamSite server
> (externaltask command line).

IWAccessorAuthenticationByFile takes care of creating the file for you. Perhaps a point of confusion is the fact that IWAccessorAuthenticationByFile only creates sessions as the current user running the current process (i.e., the JVM). So, if your JVM is running as SYSTEM, then IWAccessorAuthenticationByFile will create a session as the user SYSTEM.

> Also, wouldn't performance be worse (from Perl or .NET) if
> instead of calling the CLT the code created a temp file
> and spawned a JVM to call OpenAPI (spawning a JVM
> seems much more expensive than calling a CLT)?

That certainly seems possible. If all you are doing is creating a new workflow, then you may be better off just invoking iwjobc.

> and do you know if I can use this temp file method to
> authenticate with the SOAP API or do I not need to
> authenticate when using SOAP? looking at
> http://support.interwoven.com/library/manuals/teamportal/html/cs.110.ecis.htm
> (which I am not sure is the most recent) under
> services/session management it seems that the only way
> to create a session is with a username and password, and
> that session ID is required for subsequent transactions.

With Content Services, you need a username and a password to do almost anything. I think there is a ping() method and a getVersion() method that might not require username/password. It sounds like you are interpreting the documents correctly.

-- James

--
James H Koh
Interwoven Engineering