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

WFT to WFM

Shikha21

We have around 15 WFT with some ipl program and deployment configuration.

What is the best,faster and easy way to contert WFT to WFM ?

This is for
Windows 2008
TS7.3.1
OD7.3

Expert please share proposal for an appropriate course*of*action.

Find more posts tagged with

Comments

curiousmaverick

There are no ready to use method/utility for converting your wft to wfm.

1. If you have .wfb associated with your .wft, then first step will be to re build the skeleton using wfm gui. this will give you .ipm files.
2. Next would be to convert your external perl scripts/cgi etc to jave classes.

It wil be pretty much like building from the scratch, so I'd suggest you go for an incremental approach.

Shikha21

Thanks for reply.

First point is clear but in 2 point

can we bind external perl scripts/cgi in WFM as it is which used in WFT?

curiousmaverick

Why would you want to change it to wfm then, if you want to stick wth old perl way?

Shikha21

Curious_maverick ~We dont have soo much Time to change all WFT.

For the time being can we use WFT for new migrated TS73 and slowly we can design in WFM ?

thanks again.

curiousmaverick

WFTs should/will run w/o any issues because of backweard compatibility ( atleast they run on 7.2.1).

If there has been a direction at the organizational level to move perl bases system to a java based system, then you should consider moving to wfms. wfms open up exciting possibilities for your code by making use of the excellent API it provides.

Make your you have the visual representation of yr workflows (beeter if you have .wfb files) so that you can build those with your wfm gui.

OL_AB1424_TEMP_PERMIT.rptdesign

MP_CERTIFICATE_OF_OCCUPANCY.rptdesign

ISCBorisB

Curious_maverick ~We dont have soo much Time to change all WFT.

For the time being can we use WFT for new migrated TS73 and slowly we can design in WFM ?

thanks again.

Yes, you can usually run Perl External and CGI Tasks within WFM Model.

There are always details of course (like Task owners that may no longer be OS Users, etc...)
You'd have to plan some regression testing but then again, you will have to do that with any approach.

mart2001

Did something change? When did Interwoven actually provided "excellent" API? They perldocs that was provided was extremely useful, the java API not so much. You'll have to dig through hoops to get to those API's, or maybe decompile some of the code just to see what you can use. Most of the time, people have a hard time finding the API's required for the CSSDK they are using provided by Interwoven.

WFTs should/will run w/o any issues because of backweard compatibility ( atleast they run on 7.2.1).

If there has been a direction at the organizational level to move perl bases system to a java based system, then you should consider moving to wfms. wfms open up exciting possibilities for your code by making use of the excellent API it provides.

Make your you have the visual representation of yr workflows (beeter if you have .wfb files) so that you can build those with your wfm gui.

(Topic_39534)OS_BIRT_2.6.2_AddingReportParameterToGridViaAPI.rptdesign

Rick Poulin

Did something change? When did Interwoven actually provided "excellent" API? They perldocs that was provided was extremely useful, the java API not so much. You'll have to dig through hoops to get to those API's, or maybe decompile some of the code just to see what you can use. Most of the time, people have a hard time finding the API's required for the CSSDK they are using provided by Interwoven.

I think you're overloading the meaning of "API" here. The javadoc for the API is actually decent, and is in some respects better than the perldocs were. The API itself is fairly complete too, though the main drawback is that it doesn't allow you to do anything on the filesystem on behalf of the user. But that's TeamSiteland. The SitePub/LiveSite side is pretty terrible, I'll admit.