inline command with environment variable

Instead of setting the environment variables and trying to retrieve them in inline script.

Use the following

my ($iwhome)=TeamSite::Config::iwgethome();
this will give you the path upto d:\app\tmcrm\Interwoven\TeamSite and then u can append \iw-perl\bin\ to it.

-Dixit

waikong

Instead of setting the environment variables and trying to retrieve them in inline script.
Use the following
my ($iwhome)=TeamSite::Config::iwgethome();
this will give you the path upto d:\app\tmcrm\Interwoven\TeamSite and then u can append \iw-perl\bin\ to it.

-Dixit

Hi Dixit,

Thanks for you response.

by the way, I am new to perl and I don't understand where should I code the "my($iwhome)=TeamSite::Config::iwgethome();". Is it in the inline command tag? Or write it on the <script> section?

can you kindly guide me on this? thanks alot.

Regards,
Pang, Wai Kong

Hi Dixit,

Thanks for you response.

by the way, I am new to perl and I don't understand where should I code the "my($iwhome)=TeamSite::Config::iwgethome();". Is it in the inline command tag? Or write it on the <script> section?

can you kindly guide me on this? thanks alot.

Regards,
Pang, Wai Kong

Sorry, I made a big mistake while reading ur post. I will get back to you in sometime, in the meantime if somebody else helps u out, that will be great

Regards
Dixit

Sailesh

Hi Dixit,

Thanks for you response.

by the way, I am new to perl and I don't understand where should I code the "my($iwhome)=TeamSite::Config::iwgethome();". Is it in the inline command tag? Or write it on the <script> section?

can you kindly guide me on this? thanks alot.

Regards,
Pang, Wai Kong

please ignore ... Smiley Happy

waikong

please ignore ...

Thanks, anyway, do anyone got any solution for my problem?

TestReport.rptdesign

If you look through the forum you'll find a number of similar posts.
For one reason or another, Interwoven has never provided a means of symbolically referencing the IWHOME path within inline command strings - despite requests for such for a number of years now.

The "solution" here is that you should make sure all your environments have TeamSite installed in identical paths - and then when you hard-code the path into DCTs like this, it will work in all your environments.

However - you should file a feature request with Interwoven Support

Thanks, anyway, do anyone got any solution for my problem?

Note that FormsPublisher currently does not provide any *substitution* functionality for inline's command attribute.
You have to hardcode the path.

That said, it looks like all you need is a path to iwperl interpreter. You may try to code just <inline command="iwperl Y:/...">
and modify server's PATH environment variable to include corresponding ...iw-perl/bin directory. Matter of fact, I *beleive*
standard installation modifies PATH for you.

In prior versions you could use use __IWHOME__.

Teamsite Templating Developers Guide Release 5.0
page 69

But I guess they dropped that in the newer releases.

In prior versions you could use use __IWHOME__.

Teamsite Templating Developers Guide Release 5.0
page 69

But I guess they dropped that in the newer releases.

It's in the example in the 551 and 552 manuals too (page 73) - but if you look closer, its all within a comment - note the end of the comment:

            <!-- To use the example server-side 
                 inline callout, uncomment the 
                 next line for UNIX: 
<inline command="__IW_HOME__/iw-perl/bin/iwperl     __IW_HOME__/examples/ 
Templating/config/example_server_side_inline_callout.ipl" /> 
                 or this line for Windows NT: 
<inline command="__IW_HOME__/iw-perl/bin/iwperl.exe __IW_HOME__/examples/ 
Templating/config/example_server_side_inline_callout.ipl" /> 
replacing "__IW_HOME__" with 
                 the location of your TeamSite 
                 installation. -->

I don't believe it was ever supported in actual DCT code.

sys.zip

Doh!! Me needs to read down a little further in the documentation next time. Sadly it was on the next line. Totally missed it.

Okay, I spent a little too much time on this, but I think I finally have something that will work. It's a little hokey, but what the hey.

Make sure you create an environment variable called tshome and point it to your iw-home directory. If you have an environment variable already setup that points to your iw-home directory then change the bat file to use that environement variables name.

I have attached inline command, the ipl and the bat. Basically, the inline command calls the batch file which reads the environment variable called tshome and uses it to call perl within the bat file. This perl then calls another perl file (passed to it via the inline command). The output of the perl file is then printed to the DCT.

You could place all your perl in the bat file, but using the bat file to call a ipl file makes it more dynamic.

Okay, I spent a little too much time on this, but I think I finally have something that will work. It's a little hokey, but what the hey.

Make sure you create an environment variable called tshome and point it to your iw-home directory. If you have one setup already change the bat file to use it.

I have attached inline command, the ipl and the bat. Basically, the inline command calls the batch file which reads the environment variable called tshome and uses it to call perl within the bat file. This perl then calls another perl file (passed to it via the inline command). The output of the perl file is then printed to the DCT.

You could place all your perl in the bat file, but using the bat file to call a ipl file makes it more dynamic.

Alternatively you might have (as indicated before) use bare iwperl in <inline command="iwperl whatever"> and
add proper bin directory to server's PATH Environment variable. Granted, your solution provides much better *job security*

Okay, I spent a little too much time on this, but I think I finally have something that will work. It's a little hokey, but what the hey.

Make sure you create an environment variable called tshome and point it to your iw-home directory. If you have an environment variable already setup that points to your iw-home directory then change the bat file to use that environement variables name.

I have attached inline command, the ipl and the bat. Basically, the inline command calls the batch file which reads the environment variable called tshome and uses it to call perl within the bat file. This perl then calls another perl file (passed to it via the inline command). The output of the perl file is then printed to the DCT.

You could place all your perl in the bat file, but using the bat file to call a ipl file makes it more dynamic.

And how do you point to the location of the batch script?

Alternatively you might have (as indicated before) use bare iwperl in <inline command="iwperl whatever"> and
add proper bin directory to server's PATH Environment variable. Granted, your solution provides much better *job security*

I'd agree that this sounds like a better choice - but

I thought over another solution. u may follow this only if it is not at all possible to re-install the TS in similar locations on all the three env.
Though this might seem little complex.

Following are the three main components

1. Main branch --- this is the place where the datacapture.cfg is first coded. In the Datacapture.cfg's provide a placeholder for the path of iw-home. something like what you have already done

inline command="%iw_perl%\iwperl.exe Y:\default\main\crmkb\WORKAREA\p1\templatedata\tm_ subject_area\products\list_products_access_ctrl.ip l"

2. Sub branch --- Datacapture.cfg from main branch are deployed onto this subbranch, only after replacing the placeholder(%iw_perl%) by the correct path of iw-home.

3. Deployment Script:

Now provide a custom link in the menu to fire a deployment script which will deploy from main branch to sub branch. The script will have a logic to replace the placeholder %iw_perl% by the environment specific path depending on which environment the file is being deployed.

You may directly deploy from the main branch of the devl server to the other servers, in the similar fashion as in, before deploying replace the placeholder by the correct iw-home path.

This is little crude, but you can build on this, if u convince the business.

However, the best bet is install TS at similar locations on all the environments.

-Dixit

are you sure the PATH environment is read by the DCT processing engine?

I'm positive

and you still need to reference the path to the script to be run

I agree, that's the problem. I *beleive* there is a FR for it.
However, please remember Waikong's issue: <inline command="%iw_perl%\iwperl.exe Y:\default\main...>
That's exactly what I've tried to help him with. Broader *dynamic inline* problem is up to IWOV to address.

And how do you point to the location of the batch script?

Ghoti, did you look at the inline callout portion of the attachment? He can create a standard location for batch files that is mimicked on each server. Example c:\batch.

Granted, your solution provides much better *job security*

What? You don't like being employed. J/K I was just working on creating a solution without placing something in the environment. Just as a challenge to myself. Placing the path to the perl file in path system environment variable is the solution. Which Waikon had already proposed. But never followed through with. If he would have just followed through on his original thoughts the problem would have been solved.

One note about adding the path to the perl bin location. It will work fine unless you have multiple versions of per installed. Then it could possibly mess up other apps on the server, not a likely scenario, but possible.

I just added the path to the perl bin folder into the systems PATH environment variable, restared the server (you must restart the server, doing a iwreset -a will not work) and voila, it worked.

Ghoti, did you look at the inline callout portion of the attachment? He can create a standard location for batch files that is mimicked on each server. Example c:\batch.

Yes - but if he's going to do that, he should just fix the installation directory for IWHOME so that it's a standard location.

The larger issue, which is to what I was referring, is that there's no symbolic mechanism that can be used to reference things like IWHOME in the command attribute - which I consider to be a significant oversight in what is otherwise a very nice feature of the DCT coding. This issue exists for both Windows and Unix.

On Windows - as has been pointed out - you can reference iwperl directly assuming it is on the PATH, but the script you run also needs to be referenced. If you want to collect a bunch of batch scripts in some place outside of IWHOME you can do so, but IMO that's poor architectural design.

On Unix you don't need to specify the path to iwperl, but you still need the path to the script. You could create shell-scripts to act like the batch scripts on Windows - but it's the same bad design.

So your choices appear to be:

I thought someone had posted something before where they managed to create an XML entity for IWHOME and add it to the DTD for the DCT on-the-fly - but I don't remember all the details and whether or not it was successful.

What? You don't like being employed. J/K I was just working on creating a solution without placing something in the environment. Just as a challenge to myself. Placing the path to the perl file in path system environment variable is the solution. Which Waikon had already proposed. But never followed through with. If he would have just followed through on his original thoughts the problem would have been solved.

One note about adding the path to the perl bin location. It will work fine unless you have multiple versions of per installed. Then it could possibly mess up other apps on the server, not a likely scenario, but possible.

I just added the path to the perl bin folder into the systems PATH environment variable, restared the server (you must restart the server, doing a iwreset -a will not work) and voila, it worked.

I like being employed as much as the next guy. I like consulting even better.

Please note that:

a) What Wiakong tried would not work, followed through or not. TST Engine forks it's own environment,
PATH is inherited but your *custom* variables are ignored.

b) Multiple perls are not that unlikely, I have two on my laptop alone. Note however that I proposed to
include iwperl bin directory. It is not allowed to have several TS Installations on the same box.
So, no multiple iwperl's and no possible mess.

c) You still have to place something into environment. Do you think that batch File is somehow superior to
environment variable?

Multiple perls are not that unlikely, I have two on my laptop alone. Note however that I proposed to
include iwperl bin directory. It is not allowed to have several TS Installations on the same box.
So, no multiple iwperl's and no possible mess.

Having the iw-home\iw-perl\bin in the path won't mess with the iwperl.exe but it may mess with perl.exe since there is a perl.exe in the iw-home\iw-perl\bin folder. This could cause issues with other non-Teamsite apps that work with another version of perl on the box. However, this still is probably not that common of an issue.

c) You still have to place something into environment. Do you think that batch File is somehow superior to

Uhmmm.... no, I never said that. If you read my previous post you will see that I said that the environment variable is the correct way "Placing the path to the perl file in path system environment variable is the solution." . When I said perl file I meant iwperl. Not the ipl. Maybe I needed a little more clarification on that , jeeesh.... calm down.

Jeeesh.... calm down.

I thought we are calmly discussing some technical aspects of teamsite templating...
Sorry if you mistook it for the **** contest :-(

You could have just left out the following jab and I wouldn't have felt a little slighted.

Granted, your solution provides much better *job security*

You could have just left out the following jab and I wouldn't have felt a little slighted.

I apologise... That was completely uncalled for.