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

Workflow modeler and attaching dcrs...

dchristie

We are starting to upgrade our TS environment from 6.5 to 6.7.2 and it looks like we will have to re-write a lot of our custom java scripts to work with the new TS. Our custom scripts were doing simple tasks such as attaching a blank dcr to the workflow, or retrieving a previous published one.

My question is about the modeler. Is there any built in functionality to start a workflow and have a dcr attached? Or will we still have to rely on external calls? Furthermore, is the wf modeler a benefit to use? Or should we update our old workfolows and continue to use the older scripted style?

Find more posts tagged with

Comments

vpatel

We are starting to upgrade our TS environment from 6.5 to 6.7.2 and it looks like we will have to re-write a lot of our custom java scripts to work with the new TS. Our custom scripts were doing simple tasks such as attaching a blank dcr to the workflow, or retrieving a previous published one.

I wonder why? WFM should work fine here. If you used Java code for your external tasks with WFTs then you should be able to use it with WFM just fine with relatively small tweaks. For the most part, WFM provides tasks that are very similar to WFT.

My question is about the modeler. Is there any built in functionality to start a workflow and have a dcr attached? Or will we still have to rely on external calls? Furthermore, is the wf modeler a benefit to use? Or should we update our old workfolows and continue to use the older scripted style?

Do you have SP/LS? If you have PLC WF, then it provides some "dependency management/attachment" features OOTB. Also if upgrading your old WFT WFs to WFM WFs is an option then go for it. WFM is the recommended technology -- WFT is legacy technology (but still supported). Most of the newer features / functionality tend to be available in WFM.

HTH!

Adam Stoller

I WFM is the recommended technology -- WFT is legacy technology (but still supported). Most of the newer features / functionality tend to be available in WFM.

I realize this is the "party line" - but as both WFT and WFM end up utilizing the same workflow engine (unless that's changed?) - until IWOV announced such a change, there's no compelling reason, IMO, to switch from WFT to WFM ... "if it ain't broke, don't fix it".

If you are developing new workflows - that's a slightly different story. If you're comfortable with Perl (and are not using Non-OS Users), then stick with WFT. If you prefer to code in Java and JavaScript (or are using Non-OS Users) - then you should probably be looking into using WFM.

(one can use Java or Perl for automated [externaltask, cgitask, urltask] task script functionality in either WFT or WFM)

While I think WFM is significantly better than "workflow builder" ever was - I think the UI makes things harder than they need to be, and the graphics stop being very useful when you start adding timeout and error handlers to your process - and despite the sales-pitch, WFM is not really for use by "management" - it still needs a developer to use it correctly.

dchristie

With this upgrade, we were under the impression that since our workflwo use the OpenAPI we would have to re-write our java programs. Isn't OpenAPI no longer in use with 6.7.2? Is the SDK that is there going to work with our old code? We were thinking no.

Adam Stoller

With this upgrade, we were under the impression that since our workflwo use the OpenAPI we would have to re-write our java programs. Isn't OpenAPI no longer in use with 6.7.2? Is the SDK that is there going to work with our old code? We were thinking no.

You didn't say your existing scripts were using OpenAPI before.
For that code, yes, you will probably have to rewrite it using CSSDK - however that still doesn't require that you switch from WFT to WFM (it doesn't prohibit you from doing so either - it's completely up to you)

dchristie

You didn't say your existing scripts were using OpenAPI before.
For that code, yes, you will probably have to rewrite it using CSSDK - however that still doesn't require that you switch from WFT to WFM (it doesn't prohibit you from doing so either - it's completely up to you)

Sorry, yeah I'm sure we'd have to rewrite the code for the CSSDK. The majority of our java calls were just to add a blank DCR to the workflow when the user started them. When we first installed Team Site many moons ago since we a major Java house we choose to write those programs in Java, but I think we could of just used PERL instead and life would be more simpler. I seem to recall there being sample PERL scripts that were bundled with TS taht? Does anyone know if this was the case and what the name of the file may be?

Adam Stoller

Sorry, yeah I'm sure we'd have to rewrite the code for the CSSDK. The majority of our java calls were just to add a blank DCR to the workflow when the user started them. When we first installed Team Site many moons ago since we a major Java house we choose to write those programs in Java, but I think we could of just used PERL instead and life would be more simpler. I seem to recall there being sample PERL scripts that were bundled with TS taht? Does anyone know if this was the case and what the name of the file may be?

I'm not sure that there were perl scripts shipped OOTB that did exactly what you want - but if you're at all proficient in Perl, from what you describe as the function of the code, it should be pretty trivial scripting.
If you prefer to use Java, then go forward with that approach (switching to CSSDK).