Reviews needed on new TS 6.7.1 Workflow Modeller!

Our company uses a different workflow tool to connect to interwoven, with a very shakey java piece holding both together. The workflows have become far too complex to both maintain and for our users...

Im very interested in how the new TS 6.7.1 workflow modeller is, ive read thru the documentation and the pitch paragrph sounds good...any real world reviews/opinions?

"New Workflow modeler: A graphical user interface with a visio like environment to design and build workflows with support for Business Process Modeling Notation (BPMN). It seamlessly integrates with TeamSite Content Center for version control of workflows. It provides a web based graphical view of the workflow including the highlighting of workflow status. This new workflow modeler simplifies the creation and configuration of workflows to automate the business processes that drive web publishing within enterprises. "

Find more posts tagged with

Comments

IwovHeather

Hi,

In addition to any first-hand use cases of the new Workflow Modeler, we had a TeamSite 6.7.1 webcast on DevNet with a short demo with Meili showing how to use it:

http://devnet.interwoven.com/site.fcgi/webcasts/docs/webcast-recordings.html#webcast06-23

Hope that helps,

Heather

boskovuk

I am curious to hear about Modeler support for previously created workflow templates (.wft files).

WorkflowBuilder could not be used to edit workflow templates that have not been created using WorkflowBuilder.

How is this solved with Modeler?

birt_dates.png

Migrateduser

thanks, im signed up for the webcast 2moro was lookin for prelim info, this will help. thanks!

smenon

The new WF Modeler will not recognize or work with the old WFTs. There was no way to interpret all the Perl code in the WFTs and produce an equivalent WF Model in an automated utility. Unfortunately, you will have to re-create the WF in the new modeler. The good news is that it should be pretty easy now with the graphical drag and drop interface Smiley Happy

Migrateduser

Sunil, whats your guess on how simple it would be to use the new WFM to create a demo for our internal clients to see if they like it vs our current bloated system?

our company is extremely concerned w/ SOX and compliance approvals...

Frederik

What I was wondering about when hearing about this GUI approach:

(a) how does the WF modeler save the WF? Is it natively saved as (or exportable as) a text format (xml, whatever), that can be *read* (printed, studied, annotated) by *developers*?
(b) How about versioning of such WF and comparing different versions of WF?
(c) How does one transfer such a WF from one server to another?

I find that having a meaningful text format tends to facilitate (b) and (c) although it's probably not a strict pre-requisite.

(Sorry, didn't read the docs yet. Could be a case of RTFM Smiley Surprised

)

ISCBorisB

What I was wondering about when hearing about this GUI approach:

(a) how does the WF modeler save the WF? Is it natively saved as (or exportable as) a text format (xml, whatever), that can be *read* (printed, studied, annotated) by *developers*?
(b) How about versioning of such WF and comparing different versions of WF?
(c) How does one transfer such a WF from one server to another?

I find that having a meaningful text format tends to facilitate (b) and (c) although it's probably not a strict pre-requisite.

(Sorry, didn't read the docs yet. Could be a case of RTFM )

It seems that WFs are saved as DCRs (exposed through Administration Tab) or at least some assets using the same Datacacpture interface for editing.
Not sure what's generated out of that.

*meaningful* text format is often convenient. It also exposes your tool to the huge can of warms named "Round Tripping...."

Valentine

Great! It looks like it requires CS SDK installed.

I guess, people who don't have a SOAP license, will have to live w/o it.

Bhargav Coca

Yes its true CSSDK is important to use WM.
I want Heather or Sunil to comment on this please.
When i was working with WorkflowBuilder, I did not use any CSSDK or SOAP license to connect to TeamSite. Why is that we require CSSDK now for this New Modeler.

Well i assume its a marketing strategy to make more purchases for Interwoven by any company who wants to use WM, but any company would be happy if they were given working WM with out CSSDK.

It would have been more appropriate to Introduce some sort of complexity in WM if one gets into complexities of it and then would ask for License purchases at that point. Considering how you guys do it for DD module.

Thanks

smenon

Technically, you don't need CSSDK SOAP license to use the WF Modeler. The WF Modeler is a client application that runs on your desktop and can function in an offline mode. The WF Models themselves are saved as XML files (in BPMN format as *.ipm files). If you are in connected mode, the WF Models can be uploaded to TeamSite where it saves the XML files (*.ipm) in an Administration store where it can be version controlled just like any other file.

The process of submiting the file into the STAGING area in the admin branch will allow the workflow to be made available for configuration and subscription to the different branches in your content stores. The subscription of the workflow model itself is very similar to the available_templates.cfg methodology that is used for WFTs, except that the available_models.cfg file is also saved in the admin store/branch. Once you have published the model (checked into staging), TeamSite will auto-generate two Forms (using the datacapture infrastructure). One of the forms is used for workflow configuration at a branch level and the other form is auto-generated based on the configuration at instantiation time. This instantiation form (DCT) is what is used to present the form to the end-user when they invoke the workflow.

You could copy the *.ipm files from one server to another as long as you copy it to the right locations in the admin store. Alternatively, you can download the model from one server to the wf modeler client and then connect to another server from the client and save it to that server, which will automatically save it to the correct location. Of course, you should remember to publish the workflow in the other server so that it is available for subscription and configuration there. If you have the same branching structure in the other server (say between test and production for example), then you could also just copy the available_models.xml from one server to the other again remembering to copy it to the right locations in the admin store.

It is true that the direct upload from the client to the TS Server occurs using CSSDK over SOAP and so if your TeamSite server does not have a SOAP license, then that functionality will not be available OOTB. You can still use all the workflow modeling functionality, except for the download and upload directly from the client. You will have upload those files from your desktop to the admin store using Content Center File Import functions.

I hope this clarifies things..

thanks

JMcNeil

I assume then that we are unable to use datasource variables in the modeler without the SOAP license?

civ3

I assume then that we are unable to use datasource variables in the modeler without the SOAP license?

Could some one confirm this? Is there any limitation if using WM offline except unable to upload models directly? Thanks.

civ3.

djo2112

What I was wondering about when hearing about this GUI approach:

(a) how does the WF modeler save the WF? Is it natively saved as (or exportable as) a text format (xml, whatever), that can be *read* (printed, studied, annotated) by *developers*?
(b) How about versioning of such WF and comparing different versions of WF?
(c) How does one transfer such a WF from one server to another?

I find that having a meaningful text format tends to facilitate (b) and (c) although it's probably not a strict pre-requisite.

I'll throw in my $0.02 cents as I have been busy moving from TS6.5 to TS6.7.1. - albet, slowly.

a) The new WFM will save workflows in XML format in both an XML & IPM file locally. You can now store this workflow information to Teamsite (an iwadmin branch) and now you "Publish" validated workflows to Teamsite as well. Whether you can read, study and annotate them, remains to seen in this forum but the mechanism is there and they will be much easier to decipher.

b) Since you can save to the Teamsite store, you automatically have the ability to version and compare. Never used this myself but then again, I'm the only one managing work flows.

c) Since we are using a new modeler, you will need to build workflows from scratch. The new modeler (1.0.0.1 - with the updated service pack) has updated samples that actually will give you good model workflows to start with and point you in the right direction.

I only had issues with the email task during various stages in the workflow process but Ghoti was able to point me in the right direction and I have posted my findings about that particular aspect of the new WFM in the forum.

The new modeler has a plethora of features, bells and whistles that should satisfy any advanced requirements and have improved the SDK for access into the class for custimization. My motto is to keep it simple and out-of-the-box, the new WFM is defintely better than the previous version.

I'm sorry I can't get into more detail here but plan on redoing ALL of your workflows. Start with the simple ones and build upon it. The WFM WebCast that was done was an extremely advanced demonstration of the new WFM and it's features so I guess I wouldn't recommend it to the novice Teamsite user. Heck, I'm still learning as I go along but I do read the manuals! They are getting better! :-)

Hope that helps a little.

-Dave