Making our leap from 7.5 to 16.4, any real world experience with using legacy wfts in new versions?

dchristie

My company is finally going to upgrade our TS system from 7.5 to 16.4.X. One of our major concerns is the backward compatibility with our legacy wfts, tpls, and custom IPLs. Has anyone used legacy wfts, dcts, tpl in the newer 16.4 systems? Of course I do expect some pains in getting the legacy stuff ported over, but I'm just looking for any suggestions on this path.

nipper

I've done 7.3.2 -> 16.3 and 8.1 -> 16.4 Both were Linux.

Legacy perl based TPL/WFTs still work. I have not seen any significant issues in relations to Perl in general.

nipper

Wanted to add one more thing to watch out.

Open issue with support. The eStudio war will not deploy in 16.4.1 if you have not set up SP/LSDS databases (i.e. you choose the nodatabase option).

If you are a legacy customer without SP, you probably would do that.

Manoj_T

Hi, My company is also planning to upgrade TS from 7.5 to 16.4.x.
How was your experience?
Could you please share what kind of challenges you face?
What approach worked for you?

Thanks

dchristie

Just now doing this, sorry Manoj. So far no major issues, still trouble shooting minor changes such as depricated "defined" tag in Perl programs. Little things so far.

Just opened a support ticket on this, but I'll ask this question for anybody out there. How can we advance the task/job id on this new build to exceed what is going on in our current Prod box? Many of our legacy workflows output files with names that incorporate the task or job id. With the new build the count was restarted, when our current prod count is > 2 million. With fear of having content published that will overwrite existing content, we need to bump up the count on the new box. Any ideas?

nipper

I assume this is a new install of a server.

I would have thought these files were temp files and would be deleted or OK to overwrite if the WF has completed.

If you really want to increment the WF number, you need to run a bunch of WFs (in a batch mode), kick them off let them run 15-20 tasks each and die. You may be able to run a nested WF that keep s kicking off children (which terminate after a few seconds) until you reach the desired number.

David Smith

In hindsight, using a datestamp may have been a better plan than using a jobid/taskid. What was the thought in using jobid/taskid in naming things? I'm curious of what use these numbers could be over time, other than (falsely) thinking they could possibly be unique?

dchristie

Issue was resolved for us. I had forgot once we migrated the /iw-store/workflows directory over the workflows continued incrementing from where we left off. This legacy design was what was put in place by Interwoven consultants back in 2004 and we have been incrementing up since then. Probably will re-evaluate this soon and migrate away from this methodology, but for now it's working just fine.

David Smith

Ahhhh - there's the crux of the problem - relying upon Interwoven consultants. Haha I'm glad you didn't get into trouble over it when you migrated your store. And who would have known this would be a problem until you ever migrated to new servers? Well, the Interwoven consultants should have known, that's who!!

ksn3

@Manoj_T said:
Hi, My company is also planning to upgrade TS from 7.5 to 16.4.x.
How was your experience?
Could you please share what kind of challenges you face?
What approach worked for you?

Thanks

Hi Manoj,

We are going to follow the same path --> upgrading TS from 7.5 to 16.4.x.
If you have already gone though this process, then could you please share your learnings, approach for the same. Thanks!

David Smith

See my comment in your other thread. Be prepared to create lots of support tickets when things go wrong, because they will.

nipper

@David Smith said:
See my comment in your other thread. Be prepared to create lots of support tickets when things go wrong, because they will.

This also depends on what product features you use. Basic TS, CCPro, OD seems pretty good on 16.4

Reports, Indexer, EStudio are pretty buggy.

David Smith

@Andy Knipp said:
This also depends on what product features you use. Basic TS, CCPro, OD seems pretty good on 16.4

Reports, Indexer, EStudio are pretty buggy.

And of course Search is a mess...

nipper

@David Smith said:

@Andy Knipp said:
This also depends on what product features you use. Basic TS, CCPro, OD seems pretty good on 16.4

Reports, Indexer, EStudio are pretty buggy.

And of course Search is a mess...

Search is part of Indexer, so yea. Also Estudio has a bunch of dependencies on things like Indexer, so if one is down, so is the other.

David Smith

Oh duh...I wasn't paying attention to what you wrote, which is pretty normal for our communication

David Smith

By the way, I had to get them to create another patch for Search that I just received today - I think based on my initial testing that Search is working completely now in 16.4.1.1. Today's patch is essential if you query for date plus time (MM/dd/yyyy HH:mm) formats. Date formats that include spaces are no bueno in the base code.

To make a long story long, Search queries are initiated to SOLR from LiveSite (lscs) now instead of TeamSite, which was the source for IDOL. They did not anticipate or test the scenario where people might query on a date field including the timestamp. There is a properties file in lscs.war that has the default date format set in it. The default is "MM/dd/yyyy". So that properties file has to be modified if you need the timestamp. We also have Java code that had to be all rebuilt using LSCS classes to query the Indexer instead of the old TeamSite classes - that's not documented anywhere. But once you change that date format to include the timestamp, the Search UI in TS won't work with date fields. Hence this new patch.