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; } } }

TeamSite 6.1 VS TeamSite 6.5

AKB

At present we are using teamSite 5.5.2 on WIndows 2000.
We are exploring the option of either moving to TeamSite 6.1 or wait for TeamSite 6.5

Wanted to know as what new features teamSite(6.5) is planning to add in the next release. One of them I know is
1) Enhanching the Reporting capability.

Thanks in advance for your help.

Thanks a lot,

Find more posts tagged with

Comments

pacer11

Hi All,

Does anyone know where I can get some concrete information about enhanced features in TeamSite 6.5. I am getting little pieces here and there but it would be nice to know where this information is.

I am especially interested in the workflow that "supposedly all implemented in Java"

Any help would be appreciated

Migrateduser

> I am especially interested in the workflow that "supposedly all implemented in Java"

That would be a huge change - I know of only a couple of customers doing ExternalTask logic in Java and .NET. Where did you hear this? It really would be useful if we could see the technical roadmap.

Migrateduser

Let's post or link to all the 6.5 rumors on this thread. I heard a lowend version of Verity K2 was integrated with TeamSite in 6.5.

Migrateduser

We had a very high level rep from IW at our last User's Group meeting, who went over the major changes for 6.5 and it is a "maintenance release", meaning primarily bug fixes. Also it is front-end bug fixes, not back-end. There was no mention of anything workflow related - I am 99% certain you will not get any Java workflow in 6.5. You will get the Search capability a lot of customers have been asking for for a long time. You will also get enhanced reporting, including some workflow reporting (not monitoring, but history of completed jobs will be available). Unfortunately, the reporting part does not come with TeamSIte - it's an add-on and you will have to buy it. Also in 6.5 will be a new group management feature to hopefully resolve many of the issues Solaris users have due to a 16 group limitation for users. I think I covered all the main things for 6.5.

I believe they are working on some sort of Java workflow, but who knows where that is in the development cycle. There is very little workflow support in the SDK. You can kick off a job and look at active tasks, but that's about it. Whoopie.

Ping your Sales Engineer to find out the timeframe for Java workflow.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

pacer11

I heard this from an Interwoven Consultant that is no longer with Interwoven. Supposedly there was also this search functionality that was to be implemented but not sure how.

Tried to contact my Interwoven Rep to get more information....still waiting....not sure if I will be getting much more than I know now..

If hear or have anything concrete to share I will post....

pacer11

Thanks for the info...a little bumed about the not having a Java workflow implementation but that's ok..One quick question if you know the answer that would be great....does this require a backingstore conversion or can we just upgrade to 6.5 using the backingstore as is (Teamsite 6.1).

Migrateduser

I am pretty certain you will be able to perform a standard upgrade with no backing store conversion.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

You can implement workflow in Java, you just have to write your own API to represent the different task and job types as objects which can write XML. Still, better than Perl.

Migrateduser

Probably better to get the info from technical people rather than marketing people.

pacer11

Have you implemented your workflows as you described...if so do you have samples of this...I would be interested in know the level of effort in coding in Java vs Perl. I know both languages pretty well but would prefer to implement in Java. Right now we don't have any workflows implemented but are in the process of requirements gathering.

Thanks much.

iwovGraduate

...Still, better than Perl....

That mostly depends on what language you are more comfortable with (java v/s perl in this case). Java is great in many ways however perl rules when it comes to things like string manipulation.

Migrateduser

I have written one Java workflow API and two .NET APIs for different clients, all including all ExternalTask logic. I probably wrote about 10 workflows total using these APIs. The .NET projects were each about three months, probably about 1.5 months of workflow coding including API and implementation; the Java one was 9 months but most of it was not the Java work. The APIs didn't support everything that comes with TeamSite such as parallel approval. On the first .NET project I rewrote from Perl 5 significant workflows using this API in a couple of days. Most of the time was actually spent testing, formatting email messages, trying to work around bugs and missing features in CCI links, etc. I had two years of Interwoven development going in, so factor that into your calculations as appropriate.

I would say that not counting analysis, testing, etc. it takes a week to analyze the Interwoven task object model (INTERWOVEN WOULD NOT PROVIDE ONE OF THEIR BIGGEST CUSTOMERS WITH THE APPROPRIATE MODEL DOCUMENTATION), 3 weeks to implement the APIs, and a day or two to write almost any reasonable workflow. I can't share the code but if you give me an email address I can send your request to the clients, who may be willing to share some code, as well as their ideas on whether this was a good idea instead of implementing Perl.

The biggest problem was with the command line tool calls, which were performance hogs in the .NET environments. I heard Interwoven provided one of the .NET customers with a DLL so they could invoke methods instead of command line tools to get the equivalent functionality. From what I've heard the other customer may still be strugling with this. Impersonation is also an issue - files commonly show modified by SYSTEM. This is a problem with non-wrapped/non-CGI Perl processes under Windows as well.

I would never code workflow in Perl again if I could avoid it. Your task types are classes with properties and methods, syntax completion, compiler validation, etc. Unfortunately most projects don't resource the required development to get away from the Perl kludge.

Edited by john on 07/27/04 01:28 PM (server time).

Migrateduser

I don't want to start another religious war and I agree that Perl has it's place, but for me it's just not a good foundation for enterprise-class applications. Even Interwoven now seems to recognize this.

iwovGraduate

I have no interest in any java v/s perl "religious war" either. Both have their own place. The point I am trying to make is not whether to use Java or Perl, but whether to use whats supported or spend months building something that will not be supported and may become obsolete with upgrades.

You stated your opinion/experience. I am expressing mine. It was probably a good solution for a few customers, may not be vialbe for everybody. You have already mentioned a few reasons yourself Smiley Happy

smenon

TeamSite 6.5 is essentially a maintenance release for 6.1, but it does include two big features - Search and Reporting.

The Search functionality will be available with the base 6.5 product and will support both full-text and fielded parametric search capabilities. You can perform full text search on all unstructured content types such as Word, PDF, etc and fielded parametric search for DCR content, EAs and File Properties.

Reporting, as was rightly pointed out, is an optional add-on module that will enable capturing and reporting on historical event driven TeamSite data - such as information about completed jobs, submitted files, published EDITIONS etc. Reporting will also include a report center/dashboard in the CC Pro UI that will enable you to view your reports delivered through a Crystal Enterprise Server. The reporting data is written to a relational database and the schema will be published so that you could write your own complex queries or build you own reports if you chose to.

Apart from these two big features, there are other miscellaneous items including some Form API enhancements and the fix for the 16-group limitation on Solaris delivered via the ability to create and manage non-OS groups in TeamSite (applicable to both Windows and Solaris).

--Sunil Menon
Product Manager
Interwoven, Inc.

Frederik

In reply to:

Apart from these two big features, there are other miscellaneous items including ... and the fix for the 16-group limitation on Solaris delivered via the ability to create and manage non-OS groups in TeamSite (applicable to both Windows and Solaris).

my boss always told me that he heard from IWOV reps about a year ago that this rights management stuff would be the main beef of 6.5. Seems by now it's pretty down-played.

How is this group stuff supposed to work? Some LDAP integration? Would this new stuff replace the use of Unix groups / accounts, or would it be an alternative operation mode ?

We're on Solaris, but most of the IT is on Windows and moving to Active Directory / LDAP. We'd be happy to integrate the user management on AD, so that TS users wouldn't need separate (local) unix accounts and groups. Any insights ?

Thanks !

Migrateduser

The new group management is a new layer of group control within TeamSite. You can assign people to these new IW groups and then when you share branches and workareas with a group, it refers to one of these new IW groups. This theoretically eliminates the need to worry about using OS level groups to determine who gets the right to access TeamSite areas. This way I would only possibly need one Solaris group with all my TeamSite Users as members of that group and use IW groups to control access to my branches and workareas. The problem would still exist if you required more granular access control, say down to the directory or file level within a workarea. Then your IW groups would be useless. For us it will do the trick because we only require access control to the workarea level.

This solution doesn't eliminate the need to use Solaris accounts for your users to be able to access files within TeamSite. They just might not need to be members of several OS groups.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Frederik

Thanx for that feedback, Dave...

that's a bit disappointing tale though... it's splitting the rights management further into separate configs. We are using file and directory Unix permissions as it is; as well as branch / wa protections.

HTML.PNG

PDF.PNG

Frederik

seems that was your post #2000.... congrats :-)

External_Dependencies.zip

Migrateduser

So it is. Only 2108 to go to catch up to ghoti....well 2107 now with this one. And out of my 2000, at least a dozen have been serious answers to issues. I'm on a roll...

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

I agree, and when I first heard about this I was not thrilled that I'd have to maintain yet another level of user management. And to make it worse, there's no mechanism for automatically copying the user names from the existing Solaris groups to these new IW groups - it will be a very tedious manual process to put all the users in these new groups. We have hundreds of Solaris groups containing dozens of people in each group...I'm not looking forward to the process. But when it's done, it should make life a little better for us.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Gregg Faus

There has been no mention of workflow wizard customization yet. Is this going to be a feature introduced in 6.5 or am I going to have to continue to hack it?

Migrateduser

What's a workflow wizard customization?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Gregg Faus

Sorry, I guess the word "workflow" wasn't necessary. What I meant is customizing the submit wizard in CCSTD and CCPRO.

Like the ability to turn off steps or customize individual steps through CCUITK.