nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ContentServices SDK 2.0 / .NET

rpjoseph

Is anybody using ContentServices SDK 2.0? If so,

What functions are you performing with it?
Have you noticed an improvement in
- performance
- time-to-market
- ease of use
Do you recommend CS SDK 2.0

I would be especially interested to hear from anybody that is using CS SDK 2.0 in a .NET environment. We are planning to rewrite our workflows using CS SDK and would like to know if there are any issues or areas to be aware of.

Thank you.

Robert Joseph
Senior Web Engineer
CNF Inc.

Find more posts tagged with

Comments

james1

> We are planning to rewrite our workflows using CS SDK

Can you elaborate on your plan? What precisely do you mean by "workflows"?

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

You might want to check out this article:
http://devnet.interwoven.com/site.fcgi/techlib/50399

lissa

rpjoseph

Currently our Teamsite workflows (Generate, Approval, submit to other workareas, Schedule, Submit - to OpenDeploy, etc) are developed using .NET with a custom API to CLT. This, along with other factors, yields unacceptable performance in our environment.

In a nutshell - We hope to:

Develop an ASP.NET job instantiation page to replace the CGI instantiation page. Approval rules for workareas/directories/files will be stored in a database. This page will determine either a list of approvers or the sole approver for the submitted file(s), as well as collect publication schedule date and other metadata from AD and user entry
Abandon our API to CLT's and rewrite our worklfow logic using CS SDK 2.0 Web Services to:
- Assign metadata to extended attributes for each submitted file
- Generate ASP content from DCR's
- Transform Office documents to PDF using OpenTransform
- Transfer Task Ownership
- Schedule Deployment
- Deploy to Staging
- Deploy to OpenDeploy for publication to web server(s)
- Publish Content to All Workareas
- Unlock Files
- Log all activity
- Log and Handle errors

Robert Joseph
Senior Web Engineer
CNF Inc.

rpjoseph

Thank you Lissa. We have reviewed this and as much content on the subject as we can find on Support and DevNet. I appreciate you post. I am hoping for some posts that provide some 'real-world' developer experience with this new toolset.

Robert Joseph
Senior Web Engineer
CNF Inc.

james1

> Develop an ASP.NET job instantiation page to replace the
> CGI instantiation page.

Just out of curiosity, after you gather your job instantiation input data with your ASP.NET page, how will you instantiate the job that you want to have instantiated?

-- James

--
James H Koh
Interwoven Engineering

rpjoseph

Although we have not been able to test this yet - We hope to use

CSWorkflowEngine.createWorkflow()

Do you have any feedback?

Robert Joseph
Senior Web Engineer
CNF Inc.

james1

CSWorkflowEngine.createWorkflow() takes as an argument a string that is the serialization of an XML job specification. I'm wondering how you are going to generate that job specification from within your .NET code.

-- James

--
James H Koh
Interwoven Engineering

rpjoseph

We will have a WFT file that calls a .NET application and passes required parameters (such as XML Job Specification) to execute a job . We can do whatever we have to do in PERL as normal and then just pass things along to .NET.

I am hoping that you have some advice or feedback for us. Maybe I am reading you wrong but you seem skeptical that we are going to be able to do what we envision. Do you know of any issues that we should be aware of?

Robert Joseph
Senior Web Engineer
CNF Inc.

james1

> We will have a WFT file that calls a .NET application and
> passes required parameters (such as XML Job Specification)
> to execute a job

You just said that you are going to have a custom ASP.NET page for job instantiation input. So if your WFT is not going to be the job instantiation input GUI, then how are you going to interact with the WFT?

Are you going to use iwwft_compile.ipl? That tool can generate a job specification from a WFT, without instantiating the job specification. So that's good. But you will have to align your ASP.NET UI fields closely with the inputs required by the WFT, and when you change the WFT (i.e., change the workflow), you have to be careful to remember to change your ASP.NET pages accordingly. It's tricky, but do-able.

But in the end, if you are going to use a WFT, why not just have it instantiate the job too? Why insist on going through CSSDK for the instantiation of the job?

Or, if you are not going to use a WFT, but instead are going to generate job specification XML directly from within your .NET code, that is certainly possible. I would be very interested to hear more about this, if that is within your plans.

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering

rpjoseph

I think that the easiest way for us to do this is to use WFT (no UI) to hand off to .NET. Below is an example of a WFT that we could use. The WFT doesn't create or open a CGI instantiation page. Instead it calls a .NET application (in this case CNFWorkflow.exe) with parms required for starting the job, etc..

Do you think that this will work? I guess we could generate the job XML from .NET in the same way that we do it in the WFT. Do you think that would be better or easier for us? I think that it will be about the same - don't you?

<?xml version="1.0" standalone="no" ?>
<template_script><![CDATA[

#--------------------------------------------------------------------
# Purpose: Single-task Interwoven workflow model to
# redirect to an ASP page to start a workflow.
#--------------------------------------------------------------------

use strict;
use File::Basename;
use CNF::FileUtil;
use CNF::HttpUtil;
use CNF: Smiley Frustrated

ysUtil;
use TeamSite::Config;
use HTML::Entities;

#--------------------------------------------------------------------
# The parent directory containing commands, config files, etc.
#--------------------------------------------------------------------

my $iwhome = TeamSite::Config::iwgethome();
my $iw_user = __VALUE__( 'iw_user' );
my $iw_desc = __VALUE__( 'iw_desc' );
my @files = __VALUE__( 'iw_file' );

#--------------------------------------------------------------------
# Determine the workarea to associate with the job, convert to
# Windows path specification without drive letter, and throw an error
# if the user is not starting a job from the right area. die will
# cause a JavaScript alert dialog.
#--------------------------------------------------------------------

my $workarea = __VALUE__( 'iw_workarea' );
$workarea =~ s#/#\\#g;
$workarea =~ s#^[A-Z]\:##i;

if (( ! defined( $workarea )) || $workarea eq "" || $workarea !~ m#WORKAREA# )
{
die( "Navigate to a workarea and optionally select files before starting a job." );
}

#--------------------------------------------------------------------
# This variable will contain the XML representing the job, which will
# be written to the output stream when it is available so TeamSite
# will create a job.
#--------------------------------------------------------------------

my $jobXml = "";

#--------------------------------------------------------------------
# Determine the type of job to create from the name of the workflow
# model, trimming of the .wft extension.
#--------------------------------------------------------------------

my $type = basename( __VALUE__( 'iw_template_file' ));
$type =~ s#\.wft$##i;

#--------------------------------------------------------------------
# If the job description has been entered, then the form is complete,
# so try to start a job.
#--------------------------------------------------------------------

#--------------------------------------------------------------------
# A temporary configuration file for passing information to the .NET
# code to creat the job. The .NET binary will remove the temporary
# file if deletes are enabled. Create the file and write the header.
#--------------------------------------------------------------------

my $xmlFile = CNF: Smiley Frustrated

ysUtil::CNFRandomTemporaryFile() . ".${type}.jobConfig.xml";

if ( ! open( XML, ">$xmlFile" ))
{
die( "Unable to open $xmlFile for write : $!" );
}

print XML "<?xml version='1.0' standalone='yes' ?>\r\n\r\n";
print XML "<job creator='${iw_user}' owner='${iw_user}' type='${type}' area='${workarea}'";
$iw_desc = HTML::Entities::encode_entities( $iw_desc );

if ( ! defined( $iw_desc ) || $iw_desc eq "" )
{
$iw_desc = "Default ASP Workflow Description";
}

print XML ">\r\n<description>$iw_desc</description>\r\n";

#--------------------------------------------------------------------
# For each file selected by the user, remove the prefix /, convert /
# to \\ for NT, and write information about the file to the temporary
# job configuration file.
#--------------------------------------------------------------------

foreach my $file ( @files )
{
$file =~ s#^[\\/]##;
$file =~ s#/#\\#g;
$file =~ s#\0##g;
print XML " <file path=\"$file\" comment=\"\" />\n";
}

#--------------------------------------------------------------------
# Close the job config file.
#--------------------------------------------------------------------

print XML "</job>\n";
close( XML );

#--------------------------------------------------------------------
# Call .NET to write the XML representing the job to the jobXml
# variable.
#--------------------------------------------------------------------

my $cmd = "${iwhome}\\custom\\bin\\CNFWorkflow -c $xmlFile";
$jobXml = `$cmd 2>&1`;

#--------------------------------------------------------------------
# If the command returned non-zero, then the output should be an
# error message. Display the command that was run and the output of
# the command.
#--------------------------------------------------------------------

if ( $? != 0 )
{
die( "$cmd : $jobXml" );
}

#--------------------------------------------------------------------
# jobXml will be an empty string if there is no job to create
# (job description has not been specified), or XML for the job
# otherwise.
#--------------------------------------------------------------------

#]]></template_script>

__INSERT__( $jobXml );

Robert Joseph
Senior Web Engineer
CNF Inc.

james1

I think that that brought up more questions than it answered, in my mind at least.

I guess the bottom line is:

If you are going to still use some WFT technology, how are you going to interface with the WFT file? How will that WFT be invoked? How will give it the enviornment and context that it expects to be running in?

Those questions are still unanswered in my mind. Pardon me if you've already answered them and I haven't understood the answers.

-- James

--
James H Koh
Interwoven Engineering

Migrateduser

My understanding is that CNF has no Perl programmers, only C# developers and was told that Interwoven supports development of customizations (CMIs, Workflows/ExternalTasks, etc.) in any language. This is only true if ContentServices or the command line tools are used - OpenAPI is not available to C# (web service wrappers could be written in Java but the development effort could be significant). At the time of implementation ContentServices did not provide all of the functionality required so a custom .NET API was built to wrap calls to the Interwoven command line tools. Even if functionality was available through ContentServices, because there was no indication that command line tool invocation would be a performance problem, for consistency the CLTs were used across the board. This project had a very short timeframe - less than three months to define requirements, architect solutions, write the custom .NET APIs, develop templates and workflows, document, test, train and cutover to production, etc. and there was only one senior Interwoven developer on the project. I believe performance/load testing was skipped as a result of this timeframe and the customer is now trying to rebuild the airplane while it is rolling down the runway at full tilt.

All ExternalTask processes were written using the .NET API which also supports object-oriented generation of job XML. The default .wft logic is still used to invoke workflow (so that commands such as tt_data can trigger workflow instantiation). Typically a very simple .wft would post to a JSP that would create the workflow with OpenAPI using the session ID from cookies, but because LDAP is in use on this project and the local ASP.NET user (which runs CLTs when they are invoked through ASPX pages as .NET does not seem to support impersonation for invoking sub-processes on the command line) is not listed as a master in the LDAP, an ASPX page cannot be used to mimic the JSP logic described above (calling iwjobc instead of OpenAPI). So the .wft creates a small, temporary configuration file (as shown in the .wft code posted by Rob) and passes that file as a parameter to a .NET executable, which returns the XML for the job which is then written as if it had been generated by the .wft itself so that it can be invoked by the user being impersonated in the job instantiation form.

At some point Interwoven informed the customer that their performance problems were due to using the CLTs (http://devnet.interwoven.com/forums/cgi-bin/showflat.pl?Cat=&Board=PRODUCTS_TEAMSITE&Number=17633&page=&view=&sb=&o=&vc=1). The customer notices the most significant performance impact during job instantiation because the user is involved in this process but not in ExternalTask execution. The customer seems to believe that using ContentServices instead of CLTs will alleviate the performance problems. If they rewrite the customizations using ContentServices and it doesn't fix the performance problem people and servers are likely to get thrown out of windows so I would urge the customer to be very sure the CLTs are the problem and not some other factor. In the specific case of job instantiation the Interwoven command line tools are not being called directly, but the custom .NET executable is the command line being invoked (it may fork subprocesses to check extended attributes, regenerate files, etc.). I would try to trace activity and determine the exact bottleneck and look into optimizing the code or offloading it to one of the first ExternalTasks in the workflow.

They apparently want to replace all of the calls to CLTs in the ExternalTasks with calls to the ContentServices equivalents. I do not know what the authentication methodology for ContentServices is so I don't know if this is possible and if the existing .NET code for workflow instantiation could be moved into an ASPX page instead of writing a temp file and forking a sub-process from the .wft on the command line, so if Interwoven could answer this question it would be appreciated. If ContentServices provides a way of generating the job XML itself rather than using the custom .NET API (a new API for task sequence specification), the customer may intend to replace the .NET API for building job XML with the Interwoven-provided tools.

So the statement "you are not going to use a WFT, but instead are going to generate job specification XML directly from within your .NET code" is accurate - this has been done on at least 2 .NET projects and one Java project that I have been involved with. Basically each type of task required in a job is represented as a class. It is pretty tricky to determine the inheritance chain based on Interwoven documentation so functionality is somewhat limited but it's actually pretty easy to build workflows this way rather than with Perl. Both .NET projects had performance issues post-production. The first customer (in the same geographical area as CNF) played 800-pound gorilla with Interwoven and got engineering to build a DLL to replace the CLTs, which seemed to resolve some of their issues. CNF does not have this leverage.

Regardless of the response I don't believe anything in this thread is going to help the customer resolve the performance problem other than determining and correcting the existing performance impact points.

rpjoseph

Thank you John.

We are not really basing our decision to move to ContentServices API on performance issues alone. Although we do believe that there will be some performance gains by using ContentServices rather than our custom CommandLine API. We are hoping to resolve, as you stated, our issue with iwjobc and it's requirement for 'master' to execute it. But mostly - since we are going to rewrite anyway we figure that SOAP will be easier, a bit more performant, better supported by IW, and hopefully over time more feature rich.

We have walked the code thoroughly and have found that there are changes that need to be made to our Workflow application to improve performance. These changes, again as you stated, are required because of the lack of time and resources spent during implementation. The changes are significant enough that we have decided to rewrite. Not only will we improve the performance - we hope - but we will gain a much better understanding of the applicaiton which will allow us to grow and support the application better.

All I was hoping for in this thread was case study material. It would be nice if there were others that are doing or planning to do what we are planning to do. It would be nice to find some 'gotchas' up front, etc.

Robert Joseph
Senior Web Engineer
CNF Inc.

Migrateduser

I think everybody is or should be planning to use ContentServices as the primary API for TeamSite customizations not supported by the default config files and such. Unfortunately I don't know of anyone that is actually doing this (are there any 6.x customers in production other than Interwoven itself?). I can't see why you would want to call command line tools from Java or .NET if the equivalent functionality is available through web services, nor can I imagine why anyone would continue to build enterprise content management applications in Perl. Interwoven just needs to tell us how to authenticate without a username/password or sesion ID and confirm that all of the required functionality is available and thoroughly QA'd.

Interwoven?

rpjoseph

AMEN !!!!!!

I thought that they had numerous beta-testers - and that this is their most thorougly tested release. Sales people wouldn't lie to me.... would they?

Seriously though... I am not sure how they can go too wrong with exposing their functionality via Web Services. As long as all the fuinctionality is there. Well... In a few months we will be able to let everybody know how it went.

Robert Joseph
Senior Web Engineer
CNF Inc.

Migrateduser

> I am not sure how they can go too wrong with exposing their functionality via Web Services

That's what I thought when I first heard about OpenAPI. Then I found out you have to have a session ID or username/password to connect (even from localhost!) which kind of defeated the purpose for me. Later I found you could authenticate by file but it was too late and I'm still not really sure how this works. Hopefully Web Services won't present authentication problems that would defeat your goals (especially in relation to the ASP.NET user not being able to create workflows).

Let me know how it goes.

Migrateduser

John,

There's no equivalent to the OpenAPI authenticate-by-file mechanism in CS2.0. The reason for this is that since web-services are generally platform agnostic, there's no guaranteed way to tap into information like the process owner or the current logged-in OS user. The only way to do this would be to have a proprietary mechanism to communicate with the OS and provide validated information, which would defeat the purpose of writing a web-services API since it would no longer be open and platform-agnostic. On the other hand, trusting user credentials that are not validated (You say you're user X, so I believe you) would be unacceptable in terms of security.

However, in a non-CLT environment (ie a a UI environment, be it JSP, ASP.NET or even a thick client), the user will be authenticated and so you should have a session ID available (see the CSContext structure). You can still authenticate in CS using a session ID or username/password.

Hope this helps!
- Navneet

Migrateduser

Robert,
I just ran WorkflowService.createWorkflow() using C# with a user who was logged in as author and was able to:
- create two files as the user
- create a workflow that submitted the two files.

So the answer to your question is - yes, you can run the createWorkflow() method as any role, although permissions on the area and/or objects will have to be obeyed (your workflow can't be used to submit files in an area a user has no access to, for example).
HTH,
Navneet

Migrateduser

One goal is to minimize what the user has to do through the UI, especially where performance is concerned (such as generation of output files) by automating things with ExternalTasks. If I have to authenticate by username/password/session ID, ContentServices doesn't help me write generic functionality that can be used from the UI or from an ExternalTask process running on the command line - to use ContentServices I would have to write the API once using ContentServices and again using command line tools. Still the bulk of the custom activities would go through the CLTs so I am not sure I really see the value. I guess the workflow instantiator could store user credentials as a job variable or something and use that to connect to ContentServices but this also seems to defeat the security goal (and the credentials should expire quickly anyway).

If ContentServices is not a solution for this customer, I wish whoever from Interwoven had misguided them into thinking that the CLTs are the problem and ContentServices is the answer would retract their comment. It sounds like there is at least a ContentServices solution to the job instantiation problem (since that one is always done through the UI).

Migrateduser

John,
I don't believe the customer said anything about needing to write external tasks using ContentServices. They want to write an ASP.NET job instantiation page, and that's definitely wthin the realm of what CS can do. On the other hand, the WF instantion CLT requires certain user permissions to be run, which makes it harder to run from within the context of a custom UI. The answer provided by Interwoven to the customer was accurate - the CS API can be used by any user and solves their job instantiation problem.

In your scenario, on the other hand, using command-line tools does make sense. Command-line tools are a great way to implement TeamSite functionality in an external task scenario; however, they're harder to use in many UI situations since the UI requires that all jobs be run on behalf of the browser user, not the user who owns the web server process. However, if you feel like you'd like ContentServices to have additional functionality to support the specific use case of workflow external tasks, that's great input and I will make sure to pass your comments on to the appropriate people.

Finally, the goal of this release of the ContentServices SDK was to help users extend our existing user interfaces, as well as to build their own interfaces/applications using Interwoven products, regardless of what their programming tools of choice are. In that sense, ContentServices needs to be platform agnostic and cannot rely on process properties (furthermore, a remote API consumer could be on any machine), hence the design constraint.

Navneet Joneja
Interwoven Engineering

Migrateduser

This customer has mentioned to me personally that Interwoven believes that using the CLTs is the cause of their performance woes.

I would definitely say that your customers demand that your ContentServices expose all functionality. I don't see why ContentServices wouldn't expose all of the functionality required to do a complete TeamSite implementation - why would I want to write UI stuff in one language with one paradigm and back-end stuff with a different language/paradigm? Even without multiple languages, generally I end up abstracting interwoven functionality which means writing my own APIs wrapping Interwoven default APIs. Why would I want to write two APIs - one for use by UI functions that have access to a token and therefore OpenAPI/ContentServices and one for use by back-end processes which don't have a token, only the restrictions of the CLTs?

I think one of the biggest problems with most Interwoven implementation is that the APIs have never been extracted. There are so many places where I see Perl code calling command line tools directly, with no wrapper around command line tool calls (let alone functions specific to setting/retrieving extended attributes). When I do this myself it seems so easy I don't understand why it doesn't come with the base product.