Hey all,

I'm currently needing to learn about any code changes between WebFocus 7 and WebFocus 8.

I know that in WF8 you now have to have an absolute file path for your -INCLUDEs (right?). Can anyone here give me your insights as to what other possible code changes you've noticed with WF8? And/or could you point me in the right direction to some specific docs that go over comparing changes made from WF7 to WF8? I am currently looking myself. Any additional help and insights will be much appreciated.

Thanks in advance!

This message has been edited. Last edited by: CoolGuy,

CG,

Have a word with your local IB team and ask about code analysis to identify potential WF8 issues with your WF7 code base.


T

Thanks Tony. Will do.

I can tell you what we've found ( so far ).

_________________________
First ( and the biggest )
-INCLUDE stuff.

Funny thing is : The migration-tool actually creates some sort of registration of what the old path was. ( property or label or database, we don't know ).

I'll call it old-path-label.

Old includes WILL keep working. As long as you don't touch anything!

e.g.
a.fex
b.fex
c.fex ( includes a & b )

if you delete "a.fex" the old-path-label will be deleted also.
If you make new "a.fex" ( even with the same internal name etc. ) it will no longer work.

_________________________

Several links in stylesheet didn't work anymore because of the app/ prefix that had to be removed.
We ran into this with links to images and generated .svg files ( graphs )
_________________________

If you create exl2k it will make .xmh files. All users will have to assign file-type to excel in order to keep it working.
( or change all your code to xlsx )
_________________________

WHERE MYDBFIELD EQ ( &PARAM ) doesn't work anymore, lose the parenthesis.
WHERE MYDBFIELD EQ &PARAM
_________________________

Classnames in html-pages are now case-sensitive
_________________________

a TAB before including a .sty will crash it all.

ON TABLE SET STYLE *
     INCLUDE = IBFS:/WFC/Repository/general/others/companystyle.sty,
$

The space before the INCLUDE may not be a TAB. Use spaces.
_________________________

We had some trouble with parenthesis in the description of parameters.
I believe it was when importing into HTML

_________________________

A space in an output file, like xlsx, works.
"This is a file.xlsx"
But it will fail via ReportCaster
_________________________

WHERE MYDBFIELD EQ ( &PARAM1, &PARAM2, &PARAM3 )
used to work. ( accidentally I think ).
This MUST me IN ( &PARAM1, &PARAM2, &PARAM3 ) now.

_________________________

Good luck,

Interesting, we're not seeing several of these issues on 8.1.03!

-INCLUDE works just like it always did with just the filename to include, no path specified. If I'd wager a guess, is that when running such a procedure on the server (then check your PATH) or from Dev Studio (then check that the file is among the projects' paths)?

We link all our stylesheets and javascripts to /approot/{app name}/{file name}. Always did. That works on every version so far, including 8.1.03.
One little gotcha if you use deploy: If your environment is set to the wrong port number (in our case 8080 directly to Tomcat instead of 80 to IIS), then deploy will replace the URL with a FQDN one: ort%7D/etc" target="_blank">http://{serverort}/etc. I filed a bug-report for that, but IBI seems to have trouble acknowleging it as a problem.

I think that the EXL2K .xhm problem has always existed, it depends on setting the correct MIME-types. EXL2K output actually generates xhtml output, but with the "correct" MIME-type Excel gets coerced into interpreting it and then it works. I'm not sure why your MIME-types didn't get set up correctly in that case. That could be a problem with the installer.

Apparently, WHERE MYDBFIELD EQ ( &PARAM ); is shorthand for WHERE MYDBFIELD IN FILE &PARAM;

Class-names in HTML always have been case-sensitive. I'm not sure what changed there and with what code you managed to run into it. I'm guessing that WF did some case conversion (to lower or to upper case) in earlier versions. If that's true, then this change is actually an improvement, but of course a bit cumbersome if you run into it now. I would say that this was a problem with earlier versions.

I'm pretty certain that we have a TAB before our INCLUDE-sheet, which is in a generic -INCLUDE file so if that wouldn't work, none of our reports would... So perhaps that's been fixed in 8.1



Well, those are the problems that we aren't seeing. Now for those that we did run into:

One of our major remaining issues is that in random cases Dev Studio (8103) refuses to connect to the server because it's a "version prior to 8", which isn't true at all!

We also found a case where a combination of COMPUTE and LAST resulted in corrupted output, not resembling the expected values at all. Under what exact circumstances that happens we couldn't reproduce - IBI is looking into the issue - but it's a rare occurrence to say the least. Reproduces 100% of the time when it does occur though...

There's also a case where applying a style on a ACROSS values with an URL=(...) in the style doesn't function correctly. All the URL's are the same, based on just one of the ACROSS values instead of an URL per value. This is not a new issue in 8 though, we reproduced it in 7704 as well. That's one that IBI is looking into as well, apparently a fix is near.

When migrating ReportCaster jobs, the credentials are copied over verbatim-like. Unfortunately, the security model has been upgraded at 8 and those credentials are supposed to be valid authenticating users at the WebFOCUS server side. So, none of the jobs work and we couldn't manage to correct that using the user interface. We had to resort to updating the contents of the RCaster database to fix the issues we were seeing.


All in all, the conversion from 7.7 to 8.1 has been a rough road, that's for certain. It took us the better of half a year to get there in such a way that we have confidence that our reports work as expected. Most issues we had were due to either lack of understanding of the configuration (the client security XML configuration is still shrouded in mystery), plain misconfiguration or to things that were improved such that the old (often incorrect) behaviour stopped working.

A major example of the latter is that old 768 or earlier sub-servers can no longer cope with the SQL that the new server outputs. That was a major PITA for us at first, but admittedly it was about time that we upgraded those subs!

Thank you Dave and Wep5622 for your insights and experiences with trying to migrate content from 7.x to 8.x. We are attempting 7.6 content to an 8.1 environment. I've opened a case to see if I can get an IBIer to do a remote session with me this week to attempt to migrate some app content to begin with so I can get the general idea of how to migrate content across these versions. I hope to hear back soon.

Again, appreciate you chiming in!

Additional question for you all:

So, if I'm migrating content from 7.x to 8.x, utilizing the Change Mgmt. export utility, and choose to retain handles, this will enable our 7.x content to work as is in the new 8.x environment once imported? This meaning that any old syntax used for -INCLUDEs and drill downs will work in the new environment without need for modification?

From what you were trying to describe in regards to this Dave was that if we do go this route, we shouldn't modify or delete these imported files using the old syntax or things will break? Can they be included in other procedures without issue?

Would it be better for us to import our 7.x content via CM and then rework all the -INCLUDEs and drill downs to use the new 8.x syntax instead? This, so we can avoid breaking things down the road?

This message has been edited. Last edited by: CoolGuy,

On the include path...

that only goes for the Managent Reports (MR)
...now called "content".
(forgot to mention that ).


Yes, we've migrated.
We told our end-users ( MR ) just to keep working.
Just all hands of deck to fix any issue on the fly. ( or workaround )

After about two days the issue-calls dried up.

Then we spend about a week smashing through the code to fix all know possible (future) issues.



Wep,
you're right about the .xmh format. We just didn't use xlsx before because compounds weren't supported or working.

Thanks Dave!

So, Managed Reports were what the content was known as before they renamed it to just Content? I've been meaning to figure that out. The manual(s) really don't define that to the reader anywhere I've been reading. Were app directories/domains found within Data Servers in 7.x (with all their procedures, image files, etc.) considered MR?

So, thus far:

- -INCLUDE syntax changes for MR;
- drill down syntax changes;
- no boolean expressions without IF/ELSE in COMPUTEs;

- CM is for like-version only movement of apps/content/files?;

- To migrate content, we must utilize the .bat/.sh utilities found within our 8.x install, moving such & running them within our 7.x install directories, then cutting & pasting the resultant export and rc_export directories into the migration_import directory on the 8.x side. Stop the WF8 app server, etc. Then, running both mrmigrate_import.bat and rc_migrate_import.bat to finish the import. Finally, restart the WF app and distribution server?;

Has anyone here attempted a partial migration over a full migration? If so, what do we use for the domain HREF? It says "To determine a Domain HREF, right-click the Domain folder and select Properties.", but all I get is a general tab that has the domain name entered in it (domain folders in Data Servers). The manual gives an example in the format of "domain1/domain1.htm". Am I looking in the wrong place?

This thread is continued and linked to in this thread:

http://forums.informationbuild...1057331/m/9137036776