Inline Command with dynamic IWHOME in DCT

Hi Guys,

I have requirement on which I need to change the path dynamically in inline.

For E.g.

In the above Inline Command "d:\app\tmcrm\Interwoven" this can be changed for different teamsite like for dev it is same but may be in QA teamsite this can be

c:\app\tmc\Interwoven

so we need to make it dynamic. I have gone through the below link

/t5/TeamSite/inline-command-with-environment-variable/td-p/95885/highlight/true

but not able to update the same and find it quite old so posted again.

Please help me out if anyone come with any solution for this.

Thanks and Regards,

Girish

Find more posts tagged with

Comments

Rick Poulin

To digest the thread you linked, and discarding all the misinformation, your options are:

Option 1) Reinstall your environments to match each other. This might sound insane, but the effort now might actually be less than troubleshooting all the problems you're inevitably going to run into, especially if you're heavily relying on perl and CLTs. For instance, there are no options for dynamic hashbangs in your perl CGIs.

Option 2) Attempt to add iw-perl/bin to your PATH environment variable, restart the server, and see if you can reference the inline as <inline cmd="iwperl Y:\blah\blah.ipl" />

Option 3) Use a batch file at a 'known' location like C:\meow\iwperl.bat which dispatches to the 'correct' iwperl location, so you can then use <inline cmd="C:\meow\iwperl.bat Y:\blah\blah.ipl" />

Option 4) [which didn't exist in 2007] is to convert the whole thing to a Java datasource so that you don't have to care about install paths.

Girish_TCS

rpoulin wrote:
To digest the thread you linked, and discarding all the misinformation, your options are:

Option 1) Reinstall your environments to match each other. This might sound insane, but the effort now might actually be less than troubleshooting all the problems you're inevitably going to run into, especially if you're heavily relying on perl and CLTs. For instance, there are no options for dynamic hashbangs in your perl CGIs.

Option 2) Attempt to add iw-perl/bin to your PATH environment variable, restart the server, and see if you can reference the inline as <inline cmd="iwperl Y:\blah\blah.ipl" />

Option 3) Use a batch file at a 'known' location like C:\meow\iwperl.bat which dispatches to the 'correct' iwperl location, so you can then use <inline cmd="C:\meow\iwperl.bat Y:\blah\blah.ipl" />

Option 4) [which didn't exist in 2007] is to convert the whole thing to a Java datasource so that you don't have to care about install paths.

Thanks a lot rpoulin for a quick response.

It seems in our case we can go thorugh with option 2 only, please advise what extra we need to do for option2, I mean to say do we need ask client to raise a support ticket with HP so that they can customize the inline for us and we can go with option2, as it was mentioned in the thread which I refered before raising it.

Regards,

Girish Taneja

Adam Stoller

it used to be, and perhaps still is, that you could put PassEnv directives in the IWHOME/iw-webd/conf/iwwebd.conf[.template] to pass envirnment variables through to your CGIs and such. Not sure if this helps what you're tyring to accomplish or if you would need to do something in jBoss now too - but you might want to investigate it.

Option #1 is still the best choice - for many reasons. "Consistancy is Key" regardless of whether you're talking about the TeamSite servers or OpenDeploy Receivers, or branch and folder directory structures, etc. Anything else is just a hack to get around the fact that you didn't follow the golden rule.

Girish_TCS

Hi Guys,

Thanks a lot for the reply.

I had a chat with the customer and as per now they want to go for option 4. Please advise how we need to proceed if we follow fourth option and what all initial steps we need to take.

Thanks and Regards,

Girish Taneja

nipper

FInd this manual: (it is quite old), it may be in other manuals, but not many.

TeamSite®
Supplement
Release 6.7.2

Pages 17-19

Sections titles are:

Processing Scripts through iwutild.cfg

Modify the utild.cfg File

Modify the Data Capture Template

Modify the application_custom.xml File

Rick Poulin

Building datasources was also documented in detail in the WFM guide (Chapter 8 in TeamSite_WorkflowModeler_7.4.1_User_en.pdf), strangely enough. The same applies to regular DCTs.

nipper

While it is documented in that manual as well, it is much more concise in the 6.7.2 supplement.

It may be hard to get, so I will post a portion

Processing Scripts through iwutild.cfg

Users have been able to upload scripts that are on the server and call them from the form (for example, using an inline callout). Since unauthorized users could also call any script using a callout, this was a potential security issue. You can now control how inline callouts are executed.

The format for issuing inline commands in data capture templates has changed to:
<inline command="prefix:arguments" />

The prefix can be one of the following:

CLT—Run the CLT as the System user (default). This is the traditional way of specifying inline callouts in TeamSite and is fully backward compatible with anydata capture templates that you have previously developed. However, as with the traditional implementation, it is not completely secure.
Datasource—Use information from within TeamSite or from an external source, such as LDAP or a database.
utild—Execute the inline command defined in the iwutild.cfg file through the iwutild service/daemon.

The prefixes are case-insensitive. To use utild for secure inline commands, perform these steps as described in the following sections:

1. Modify utild.cfg.
2. Modify the data capture template.
3. Modify the application_custom.xml file and redeploy into ContentCenter.
4. Restart the TeamSite server.

In the Windows iwutild.log log file, each of the inline call processes using utild will show user information.

Modify the utild.cfg File

In iwutild.cfg under the <command-list> tag, add an entry similar to the following example that sets up the getLocations command:

Each command entry in iwutild.cfg must be given a name, such as getLocations in the sample.

Modify the Data Capture Template

In the data capture template, specify one of the following formats for the inline command:

When you specify the CLT prefix or do not specify a prefix, the command line is executed.

When you specify the utild prefix, the command name configured in iwutild.cfg is used. The iwutild.cfg file controls various tasks including executing commands on behalf of trusted clients with impersonation.

Modify the application_custom.xml File

To control which callout types (prefixes) are allowed in TeamSite, edit the application_custom.xml file (see the TeamSite User Interface Customization Guide).

Specify the following information:

For the value, you can enter one or more prefixes in a comma-separated list. To preserve behavior from TeamSite 6.7.1 SP1 and earlier releases, the default is:

value="CLT,Datasource"

To lock down security so all inline processing is done through command names specified in iwutild.cfg, specify:

value="utild,Datasource"

To disable all inline callouts, specify:

value="none"

Girish_TCS

nipper wrote:
While it is documented in that manual as well, it is much more concise in the 6.7.2 supplement.

It may be hard to get, so I will post a portion

Processing Scripts through iwutild.cfg

Users have been able to upload scripts that are on the server and call them from the form (for example, using an inline callout). Since unauthorized users could also call any script using a callout, this was a potential security issue. You can now control how inline callouts are executed.

The format for issuing inline commands in data capture templates has changed to:
<inline command="prefix:arguments" />

The prefix can be one of the following:

CLT—Run the CLT as the System user (default). This is the traditional way of specifying inline callouts in TeamSite and is fully backward compatible with anydata capture templates that you have previously developed. However, as with the traditional implementation, it is not completely secure.
Datasource—Use information from within TeamSite or from an external source, such as LDAP or a database.
utild—Execute the inline command defined in the iwutild.cfg file through the iwutild service/daemon.

The prefixes are case-insensitive. To use utild for secure inline commands, perform these steps as described in the following sections:

1. Modify utild.cfg.
2. Modify the data capture template.
3. Modify the application_custom.xml file and redeploy into ContentCenter.
4. Restart the TeamSite server.

In the Windows iwutild.log log file, each of the inline call processes using utild will show user information.

Modify the utild.cfg File

In iwutild.cfg under the <command-list> tag, add an entry similar to the following example that sets up the getLocations command:

<command impersonate="true" name="getLocations" path="iw-home\httpd\iw-bin\getLocations.ipl" script="iw-home\\iw-perl\bin\iwperl.exe"/>

Each command entry in iwutild.cfg must be given a name, such as getLocations in the sample.

Modify the Data Capture Template

In the data capture template, specify one of the following formats for the inline command:

<inline command="utild:command_name" />
<inline command="Datasource:datasource_reference" />
<inline command="CLT:/bin/cat /tmp/a /tmp/b" />
<inline command="/bin/cat /tmp/a /tmp/b" />

When you specify the CLT prefix or do not specify a prefix, the command line is executed.

When you specify the utild prefix, the command name configured in iwutild.cfg is used. The iwutild.cfg file controls various tasks including executing commands on behalf of trusted clients with impersonation.

Modify the application_custom.xml File

To control which callout types (prefixes) are allowed in TeamSite, edit the application_custom.xml file (see the TeamSite User Interface Customization Guide).

Specify the following information:

<applications>
<default-param id="iw.datacapture.inlineCalloutAllow" value="prefix, prefix, ..." public="true"/>
</applications>

For the value, you can enter one or more prefixes in a comma-separated list. To preserve behavior from TeamSite 6.7.1 SP1 and earlier releases, the default is:

value="CLT,Datasource"

To lock down security so all inline processing is done through command names specified in iwutild.cfg, specify:

value="utild,Datasource"

To disable all inline callouts, specify:

value="none"

HI Mark/Andy,

Thanks a lot for your qucik response and this is really very helpfull.

Unfortuantely they have change the requirement and asking to call .bat file instead of .ipl. So now we have the inline command like below:

<inline command="C:\Interwoven\TeamSite\bin\test\getInclude.bat C:\Interwoven\TeamSite\bin\test\main.xml" />

and we need to call the dynamic value of C:\Interwoven\TeamSite\ (for .bat as well as for .xml)

and it doesn't seem to be a change in our approach, so what I have understood is

To achieve the dynamic path for above inline. we need to do the following:

1) Modify the utild.cfg File:

2) Modify the Data Capture Template

3) Modify the application_custom.xml File

4) Restart the TeamSite server

Please advise I have taken you correctly or some thing different we need to do to achieve it for .bat

Thanks a lot in advance and you guys are really stars.

Regards,

Girish Taneja

nipper

That is the stupidest requirement I have ever heard. Tell them no.

Barring that run TeamSite/bin/iwcat /path/to/xml in the utild

This is not as good as running a perl script because it just dumps XML. With Perl you can have includes which include other files.

Girish_TCS

Thanks a lot for your reply. I will communicate it to them, but not sure if they will agree on it or not, and what you said is definitely making sense.

I will update the forum as soon as I will receive something from them.

Andy just for my knowledge can you please advise the steps which I have added in my previous comment(again added below) is right?

1) Modify the utild.cfg File:

2) Modify the Data Capture Template

3) Modify the application_custom.xml File

<default-param id="iw.datacapture.inlineCalloutAllow" value="utild" public="true"/>
</applications>

4) Restart the TeamSite server

Thanks and Regards,

Girish Taneja

Girish_TCS

Hi Andy,

I have discussed it with business and they need in the same as they told us before (due to some business reason and limitations of perl), in that bat file they have some jar files which they are ececuting and reading the xml.

I tried the solution by using iwutild.cfg but that is giving me an error:

"A problem was encountered trying to read the datacapture.cfg file for type product-card. Please contact your system administrator".

The steps which I followed is already posted in my previous reply as I don't won't to make this large.

Please advise if I did something wrong or how to achieve this if we have .bat file.

Thanks and Regards,

Girish Taneja

nipper

I do not know that you cna make it work with a bat file, Never tried, no reason to.

use iwcat instead and cat the XML file. Not a great solution. Otherwise you will have to figure out another approach or keep changing the paths in your DCTs

Adam Stoller

I'm curious:

What does your batch-script actually do? I.e. what does "they have some jar files which they are ececuting and reading the xml." really mean (in simple terms is fine)
What "limitations of perl" are you / they referring to?

I find it very difficult to believe that a simple inline directive can generate this many issues.

Girish_TCS

Hi Guys,

Thanks for your quick response.

Nipper: Please describe more on iwcat as this is really new for me.

Ghoti: Actually they have created the framework and we are restricted to follow the same and in teamsite they don't have libxml module due to which they switched to .bat we advised them to install but they aren't ready and want us to achieve it.

Dev teamsite is on windows where as QA and Prod are on linux so we can't hardcode it on dev so any how we need to achieve, not sure how any help would be great relief for me.

Thanks and Regards,
Girish

nipper

iwcat will print out an XML file. It is very simple functioanlity but if you have an XML only you can use it.

If there is code to be run, then you will have to either figure out how to make it work or follow Rick's iniital thought and reinstall the server to make iw-home the same. In all of the time you spent trying to get this to work, you could have reinstalled.

Rick Poulin

Girish_TCS wrote:
Ghoti: Actually they have created the framework and we are restricted to follow the same and in teamsite they don't have libxml module due to which they switched to .bat we advised them to install but they aren't ready and want us to achieve it.
Dev teamsite is on windows where as QA and Prod are on linux so we can't hardcode it on dev so any how we need to achieve, not sure how any help would be great relief for me.

Your dev team should realize that this architecture doesn't make any sense. If they insist on doing things a certain way, then they will need environments that are built to accommodate.

Adam Stoller

Girish_TCS wrote:
[...]

Dev teamsite is on windows where as QA and Prod are on linux so we can't hardcode it on dev so any how we need to achieve, not sure how any help would be great relief for me.

Hmm - and if you got this to work with Batch files on your Dev server - how were you going to make it work on your QA and Prod servers that don't understand Batch files?

Oh! You would just code it differently there - right? So you would spend all this time coding something in Dev that needs to be re-coded in QA before you have a chance of promoting it to Prod.

Yeah - that's smart! (sarcasm implied)

I'd very strongly recommend that you get all your environments on the same architecture - you're shooting yourself in both feet and costing an untold amount of wasted time trying to do it the way you described (though, perhaps that's your intention - if you're a consultant looking to bill your customer for tons of useless work - not my style, but ...)

nipper

And of course, using a BAT file is very portable. Perl on the other hand...... :-)

There are going ot be plenty of other issues because of this mixed mode install. This wil be one of your least concerns.

Girish_TCS

Sorry Guys for the delay in Post. We have found some alternative for this. i.e. we have updated the deployment script in which we are changing the path automatically.

Thanks a lot for all your help and support. you guys always rocks.

Regards,

Girish