Ok, is there a best practice for reading this file oozie prepares? Where is it? I don't want to put the el function in the actions because I have many of them and would only like to call the el function once. I am calling it multiple times now (once for each shell action).
On Thu, May 29, 2014 at 3:20 PM, Robert Kanter <[email protected]> wrote: > Ah, I see what you're saying. You could have you shell script read the > Configuration XML file prepared by Oozie; this would include everything in > the <configuration> section of the shell action and the <global> section. > Though why not simply put the EL Function directly in the shell action > instead of a variable? > > > > > On Thu, May 29, 2014 at 12:23 PM, Scott Preddy <[email protected]> > wrote: > > > Right, that what I have experienced. What I would like to know if there > is > > some mechanism in oozie where I can assign a global variable a value I > > obtain from the result of an el function and then have that value > > referenced by shell actions? > > > > > > On Thu, May 29, 2014 at 1:02 PM, Robert Kanter <[email protected]> > > wrote: > > > > > Hi Scott, > > > > > > That's not how the <global> seciton works. Properties in the > > > <configuration> in the <global> section get applied automatically to > all > > > <configuration> sections in all actions in the workflow. So, in your > > > example, "controlFilePath" is automatically included in your shell > > action's > > > <configuration> section (even though you omitted it). Putting stuff in > > the > > > <configuration> in the <global> section does not make them a variable. > > To > > > do that, it should be in the job.properties file you use to submit the > > > workflow. Once you have that, any EL Functions should accept it as an > > > argument as well. > > > > > > - Robert > > > > > > > > > On Thu, May 29, 2014 at 8:54 AM, Scott Preddy < > [email protected]> > > > wrote: > > > > > > > I would like to set a global variable to my entire oozie job and then > > > > reference its value from various actions. I would like to use some > "el > > > > function stuff" when assigning this variable. > > > > However I assume this is completely impossible because I cannot even > do > > > the > > > > following. No matter what I try "controlFilePath2" is always > undefined > > in > > > > "echoControlFile", so trying the > > > > "el function" does not even need to be explored. > > > > > > > > <workflow-app xmlns="uri:oozie:workflow:0.4" name="sandbox1"> > > > > <global> > > > > <job-tracker>${jobTracker}</job-tracker> > > > > <name-node>${nameNode}</name-node> > > > > <configuration> > > > > <property> > > > > <name>mapred.job.queue.name</name> > > > > <value>default</value> > > > > </property> > > > > <property> > > > > <name>controlFilePath2</name> > > > > <value>***Path***</value> > > > > </property> > > > > </configuration> > > > > </global> > > > > > > > > <start to="echoControlFile"/> > > > > > > > > <action name="echoControlFile"> > > > > <shell xmlns="uri:oozie:shell-action:0.3"> > > > > <job-tracker>${jobTracker}</job-tracker> > > > > <name-node>${nameNode}</name-node> > > > > <exec>echo.sh</exec> > > > > <argument>Control file path: > ${controlFilePath2}</argument> > > > > <file>${scriptsDir}/echo.sh#echo.sh</file> > > > > <capture-output/> > > > > </shell> > > > > <ok to="end"/> > > > > <error to="fail"/> > > > > </action> > > > > > > > > <kill name="fail"> > > > > <message>Job failed, error > > > > message[${wf:errorMessage(wf:lastErrorNode())}]</message> > > > > </kill> > > > > <end name="end"/> > > > > </workflow-app> > > > > "workflow.xml" 53L, > > > > 1953C > > > > 40,13 Bot > > > > > > > > > >
