OK, so I am facing an issue where I both have a shedload of reports (500+) as well as massive chaining and standardised header/footer and what not.

These have been done with classic -INCLUDE PDF_FOOTER pointing to pdf_footer.fex and so forth...

Now in version 8 we need to point to the repository "full path", so it is -INCLUDE IBFS:/WFC/Repository/Domain1/dev/std_reports/common/pdf_footer.fex

Problem being, I have a shared environment as many do, so I have... dev, tst, uat code under a domain, or then different domains set up, so like...

IBFS:/WFC/Repository/Domain1/dev/std_reports/common/pdf_footer.fex
IBFS:/WFC/Repository/Domain2/dev/std_reports/common/pdf_footer.fex
IBFS:/WFC/Repository/Domain1/uat/std_reports/common/pdf_footer.fex

And using a &ENV in the -INCLUDE isn't possible.
IBFS:/WFC/Repository/&ENV/std_reports/common/pdf_footer.fex
gives the "Names cannot contain any of the following characteres: Space&*()|:;",?/...

How have other people hacked this? The code needs to move between environments automagically without human touch, and you really can't go on a string replace spree... well, technically you might be able to replace the string in the import/export folder package, but this gets way way overcomplicated.

This message has been edited. Last edited by: Hank W.,

Create a traffic control .fex to translate your &ENV variable into the right :LABEL to GOTO the correct -INCLUDE.

 -* TRAFFIC_COP.FEX
-DEFAULTH &ENV = 'Domain1'

-SET &ROUTER = ':' || '&ENV.EVAL';

-GOTO &ROUTER;

-:Domain1
-INCLUDE IBFS:/WFC/Repository/Domain1/dev/std_reports/common/pdf_footer.fex
-GOTO :OFFRAMP;

-:Domain2
-INCLUDE IBFS:/WFC/Repository/Domain2/dev/std_reports/common/pdf_footer.fex
-GOTO :OFFRAMP;

-:Domain3
-INCLUDE IBFS:/WFC/Repository/Domain3/dev/std_reports/common/pdf_footer.fex


-:OFFRAMP

 

This message has been edited. Last edited by: Don Garland,

Or maybe try the following

-SET &ENV = 'Domain1/dev';
-SET &CALLFEX = '-INCLUDE IBFS:/WFC/Repository/' || &ENV || '/std_reports/common/pdf_footer.fex';

&CALLFEX

If I'm not mistaken, you have the extra issue of the Content area does not evaluate & variables until after the -INCLUDE is evaluated. I believe you need to either prefix your include command with -MRNOEDIT, or it has to exist on the reporting server. I remember there being some trick to getting it to work. But it won't work as expected in the content area.

You are right eric, there is an issue doing -INCLUDE &CALLFEX from the Content.

But I'm doing : &CALLFEX which will not have to evaluate a parameter in the INCLUDE since the variable have the whole string already setup and assigned.

Unfortunately I don't have the time to test it but if I remember well this is the way I have used to bypass the INCLUDE issue with WF8.

Still to confirm to it works...

Doesn't appear to work for 8009.

-SET &ENV = 'zomega';
-SET &CALLFEX = '-INCLUDE IBFS:/WFC/Repository/' || &ENV || '/QBRDashboardMetricNumbers.fex';
&CALLFEX
-RUN

The CODE above returns this:
-*-INCLUDE IBFS:/WFC/Repository/zomega/QBRDashboardMetricNumbers.fex
-SET &ENV = 'zomega';
-SET &CALLFEX = '-INCLUDE IBFS:/WFC/Repository/' || zomega || '/QBRDashboardMetricNumbers.fex';
-INCLUDE IBFS:/WFC/Repository/zomega/QBRDashboardMetricNumbers.fex
-RUN
(FOC1517) UNRECOGNIZED COMMAND -INCLUDE
IBFS:/WFC/REPOSITORY/ZOMEGA/QBRDASHBOARDMETRICNUMBERS.FEX

-SET &ENV = 'zomega';
-SET &CALLFEX = '-INCLUDE IBFS:/WFC/Repository/' || &ENV || '/QBRDashboardMetricNumbers.fex';
&CALLFEX.EVAL
-RUN  

EVAL the var and you get;
-*-INCLUDE IBFS:/WFC/Repository/zomega/QBRDashboardMetricNumbers.fex
-SET &ENV = 'zomega';
-SET &CALLFEX = '-INCLUDE IBFS:/WFC/Repository/' || zomega || '/QBRDashboardMetricNumbers.fex';
-INCLUDE IBFS:/WFC/Repository/zomega/QBRDashboardMetricNumbers.fex
(FOC227) THE FOCEXEC PROCEDURE CANNOT BE FOUND:
IBFS:/WFC/Repository/zomega/QBRDashboardMetricNumbers.fex
-RUN

Hank W.,
I did some experimenting with relative paths. I created a domain and subfolder consistent with your examples and the following does seem to work in 8.1.05 and 8.2.01.

A fex, for example,

/Domain1/dev/std_reports/report1.fex

can include another, like this:

-INCLUDE ./common/pdf_footer.fex

In my limited testing, this worked for files located along the same path in the domain/folder structure. But I couldn't get it to work for files in a peer folder not on the same top to bottom path.

ONE IMPORTANT GOTCHA: The behavior is different when running from the editor vs. running it from the tree.

We have a different repository for each environment.

Thanks guys... I experimented a bit and it looks like I am getting the behaviour of a cd command in the -INCLUDE as dbeagan pointed out.

I think for my purposes it's easier to hardcode the relative path than do a logic.
(Might got to do with losing my mojo hearing WF is going to be replaced in a couple of years, so my hacks won't survive the time )

We have a common folder structure between our development, test and production environments. I can use this syntax and freely move focexecs between environments:

 
-INCLUDE IBFS:/WFC/Repository/Financial_Insight/Hidden_Content/Controller/Encumbrance_X_Payment_Information.fex
 

Yes, it works fine if you have one environment per box. Once you get into sharing boxes the can of wiggly worms comes out.

quote:

Originally posted by Don Garland:
Create a traffic control .fex to translate your &ENV variable into the right :LABEL to GOTO the correct -INCLUDE.

 -* TRAFFIC_COP.FEX
-DEFAULTH &ENV = 'Domain1'

-SET &ROUTER = ':' || '&ENV.EVAL';

-GOTO &ROUTER;

-:Domain1
-INCLUDE IBFS:/WFC/Repository/Domain1/dev/std_reports/common/pdf_footer.fex
-GOTO :OFFRAMP;

-:Domain2
-INCLUDE IBFS:/WFC/Repository/Domain2/dev/std_reports/common/pdf_footer.fex
-GOTO :OFFRAMP;

-:Domain3
-INCLUDE IBFS:/WFC/Repository/Domain3/dev/std_reports/common/pdf_footer.fex


-:OFFRAMP

 

I am a bit puzzled how that scheme can succeed in pulling in the right version based on &ENV

1. For each Client-side -INCLUDE statement (with IBFS:/WFC/Repository/...), the Client arranges to upload the referenced fex file to the Reporting Server along with the report script, and replaces the -INCLUDE statement in the script with a Server-side -INCLUDE that points to the uploaded copy.

2. Thus by the time the Reporting Server gets to evaluate &ENV and perform the -GOTO, the contents of all three fex files are effectively present as static code in the report fex.

3. If anything goes wrong within the Included code, the Reporting Server is able to reference the correct fex name and line number.


So how does it come about that the three server-side -INCLUDEs wind up pointing to local fex files on the server with identical filenames but with different code content (obtained from the respective Domains)?

@dbeagan:

quote:

... the following does seem to work in 8.1.05 and 8.2.01.

A fex, for example,

/Domain1/dev/std_reports/report1.fex

can include another, like this:

-INCLUDE ./common/pdf_footer.fex

In my limited testing, this worked for files located along the same path in the domain/folder structure. But I couldn't get it to work for files in a peer folder not on the same top to bottom path.

Did you try "./../siblingdomain/etc"?

I can get around as if it were a CD command,
Repository/dev/here/there/somewhere/fex1.fex
Repository/tst/nothere/orthere/anywhere/fex2.fex

So in fex1 I could use

-INCLUDE ../../../nothere/orthere/anywhere/fex2.fex

For the last couple of years I've been working on an application were we do not have 'variable named' paths in the Repository Content folder structure.

I am now going back to work on one of our legacy systems were environment is built into the path names. e.g., ../dev/reports.. ../uat/reports..

The issue with -INCLUDE and variable pathing is discussed in Doug's tread below, as well as, this one.
http://forums.informationbuild...017011386#7017011386

I'd like to add a comment and a request to this thread.

My comment is that I took at look at the case I opened just now, and see that my NFR was rejected by IB Engineering on 9/18/2014 (case 10553585). If anyone else created a NFR, was your request rejected as well?

My request is to ask if the 'traffic control' workaround is the only workaround available? Are there any other workarounds, that someone would be willing to share?

This message has been edited. Last edited by: David Briars,