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

Migration from TS 6.0 to TS 6.1

Linio

Dear all,

In the process of migrating our entire environment to the latest teamsite version we need to update first to TS 6.1

I've done it on our qualification platform, but it appears some things are not working anymore, whereas we though there were only few changes in this version.

Since none of our template were working anymore, i rolled back the PERL environment to the one used in TS 6.0 (5.0 instead of 5.8), then all the templates worked again, but now, i'm having error 500 while trying to submit (but the whole submission goes well).

Somebody have any clue on this? I know this version is not supported anymore, but i must do this migration before considering the rest.

Find more posts tagged with

Comments

Adam Stoller

Dear all,

In the process of migrating our entire environment to the latest teamsite version we need to update first to TS 6.1

I've done it on our qualification platform, but it appears some things are not working anymore, whereas we though there were only few changes in this version.

Since none of our template were working anymore, i rolled back the PERL environment to the one used in TS 6.0 (5.0 instead of 5.8), then all the templates worked again, but now, i'm having error 500 while trying to submit (but the whole submission goes well).

Somebody have any clue on this? I know this version is not supported anymore, but i must do this migration before considering the rest.

Personally, I would have tried to figure out why the Perl code was breaking before rolling it back to an incompatible version (all the TeamSite modules were updated to use the newer version and might not work with the older one). Chances are, the fixes to your existing Perl code would have taken far less time than the effort you're putting in now trying to retrofit things to work in a "broken" environment.

I'd recommend starting from scratch with a fresh installation and debug your existing Perl code rather than trying to press forward with an old version of Perl in a new version of TS (btw - why are you going to 6.1? if you're going to upgrade you should probably be focused on 6.7.2)

Linio

About the why of the 6.1 this is rather complicated to explain, but let's say there is no option there.

About the migration of the code, you're probably right, then again the library structure is not the same in the new perl version (apparently), and i'm assuming this is the major "issue" that we're having here.

On our previous environment home made perl libraries were stored under : iw-home\iw-perl\site\5.00503\lib so i'm assuming, now we can directly put them under site\lib, but it does not seem to work, and i'm not aware of any procedure to reinstate perl modules for this version.

Adam Stoller

About the why of the 6.1 this is rather complicated to explain, but let's say there is no option there.

About the migration of the code, you're probably right, then again the library structure is not the same in the new perl version (apparently), and i'm assuming this is the major "issue" that we're having here.

On our previous environment home made perl libraries were stored under : iw-home\iw-perl\site\5.00503\lib so i'm assuming, now we can directly put them under site\lib, but it does not seem to work, and i'm not aware of any procedure to reinstate perl modules for this version.

Which version are you referring to here?

If you have the proper version of iwperl installed - and you put your custom modules into iw-perl/site/lib (yes - you were correct there) - then you need to debug your perl scripts to find out why they're failing.

If you have the wrong version of iwperl installed - perhaps you can use another machine to do a temporary installation of 6.1 on (use the same path for IWHOME) - and then replace the entire iw-perl directory on your real server with the iw-perl from the temporary installation - and then debug your perl scripts to find out why they're failing.

I recommend putting the following in all your perl scripts and modules:

use strict;
use warnings;

and testing all scripts with iwperl -w -c script-name

Linio

I kept the right perl version.

But the problem I have is not on the workflow per se, but when i'm trying to trigger a workflow i have a 500 error : "The server encountered an internal error or misconfiguration and was unable to complete your request."

I have nothing into the IIS logs...

So it does not even come from the PERL files, but where is the problem is a mistery.

I can't use the command for template_checking since it fails at the first line saying :

"use" not allowed in expression at default_submit.wft line 36, at end of line
syntax error at default_submit.wft line 36, near "use strict"
BEGIN not safe after errors--compilation aborted at default_submit.wft line 37.

Error 500 raised even on OOTB workflows...

Adam Stoller

I kept the right perl version.

But the problem I have is not on the workflow per se, but when i'm trying to trigger a workflow i have a 500 error : "The server encountered an internal error or misconfiguration and was unable to complete your request."

I have nothing into the IIS logs...

So it does not even come from the PERL files, but where is the problem is a mistery.

I can't use the command for template_checking since it fails at the first line saying :

"use" not allowed in expression at default_submit.wft line 36, at end of line
syntax error at default_submit.wft line 36, near "use strict"
BEGIN not safe after errors--compilation aborted at default_submit.wft line 37.

Error 500 raised even on OOTB workflows...

Is this your own "default_submit.wft? Or a modified version of the OOTB wft?
Can you post the WFT --- as an attachment?

Linio

It was a "modified" one.
But even when i try with a OOTB submit, i do have the same problem.

Join the unmodified Workflow

Adam Stoller

It was a "modified" one.
But even when i try with a OOTB submit, i do have the same problem.

Join the unmodified Workflow

I don't really feel like trying to figure out all the issues here - but I suggest you start by un-dos-ifying the WFT (i.e.: removing all the ^M's at the end of each line).

Here's a nice simple script for doing it - if you don't already have one available:

use strict;
use warnings;
die("Usage: $0 file [file ...]\n") if (!@ARGV);
foreach my $file (@ARGV) {
    print STDERR "# $file ...\n";
    open(IN, "<", $file) || die " '$file' ($!)";
    my $text = do {local $/; <IN>};
    close(IN);
    $text =~ s/\r//gsm;
    open(OUT, ">", $file) || die " '$file' ($!)";
    print OUT $text;
    close(OUT);
}
exit 0;

nipper


use strict;
use warnings;
die("Usage: $0 file [file ...]\n") if (!@ARGV);
foreach my $file (@ARGV) {
    print STDERR "# $file ...\n";
next if (-b $file); 
    open(IN, "<", $file) || die " '$file' ($!)";
    my $text = do {local $/; <IN>};
    close(IN);
if ($text =~ s/\r//gsm) {
    open(OUT, ">", $file) || die " '$file' ($!)";
    print OUT $text;
    close(OUT);
}
}
exit 0;

Making Adam's code a little more efficient. Having used scripts like this in a Unix find command it is important to skip binary files and also if the file is not changed don't update.

I tend to blast this through a complete structure and these changes make it benign.

Adam Stoller

Making Adam's code a little more efficient. Having used scripts like this in a Unix find command it is important to skip binary files and also if the file is not changed don't update.

I tend to blast this through a complete structure and these changes make it benign.

Hmm - good additions (though I tweaked it a bit more) - I don't think I bothered with the tests because I was expecting explicit files to be provided on the command line when I first wrote it, as opposed to processing an entire tree of files; but it makes sense to make it work that way too. However, if you're going to do that, you could bullet-proof it more (like skipping directories, and maybe symlinks, and other "special files") and other things - but I'll leave that up to the individual who wants to use the code to do so.

BirtReportGenerator.java

nipper

However, if you're going to do that, you could bullet-proof it more (like skipping directories, and maybe symlinks, and other "special files") and other things - but I'll leave that up to the individual who wants to use the code to do so.

Yea but directories get caught with the next if (-b $file); statement

I never tried sym links (I hate them)

Linio

It's not changing anything.

I'm still quite sure this is not linked to template issues.

I'm having an error 500 on :
/iw-bin/iw_cgi_wrapper.cgi/iwwft_instantiator.cgi

Adam Stoller

It's not changing anything.

I'm still quite sure this is not linked to template issues.

I'm having an error 500 on :
/iw-bin/iw_cgi_wrapper.cgi/iwwft_instantiator.cgi

You may be right - that the ^M's have nothing to do with the 500 error - I was responding to the other errors about not being able to use

use

statements and such, that you reported - which to my mind means that something isn't being processed correctly, or there's a significant syntactic error somewhere - but I didn't see any indication of a syntactic error in the WFT code you posted, but I did see ^M's.

I'm not sure what's generating the 500 error - and thus far nobody contributing to this thread seemed to have any significant input there either - so I suggest you try contacting Support.