Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Wiki Markup
{scrollbar}

----
The Action Sequence document is the definition, the Runtime Context provides an execution environment and the Components are the business logic.  A Component performs a single function, a group of related functions or is a bridge between the Pentaho BI Platform and an external application.  The jFree Reports component is an example of a component that interfaces the platform to the jFree Reports reporting engine. 

There are two major functions that a Component gets called to do - validate and execute.  Validate is called to verify that the inputs are valid and all resources required to execute are available.  Execute actually performs the action. 

The action-definition node in the Action Sequence document defines how the component should function.  It is the place to define and map inputs, outputs and any other metadata or settings the component will require when it is executed.  The name of the component that executes the action definition is identified using the component-name node.  The name is the name of a Java class that is dynamically loaded at runtime.  When referring to the built in Pentaho components, the fully qualified name of the component should not be used, just the class name. For example, use EmailComponent instead of 

The Action Sequence document is the definition, the Runtime Context provides an execution environment and the Components are the business logic.  A Component performs a single function, a group of related functions or is a bridge between the Pentaho BI Platform and an external application.  The jFree Reports component is an example of a component that interfaces the platform to the jFree Reports reporting engine. 

There are two major functions that a Component gets called to do - validate and execute.  Validate is called to verify that the inputs are valid and all resources required to execute are available.  Execute actually performs the action. 

The action-definition node in the Action Sequence document defines how the component should function.  It is the place to define and map inputs, outputs and any other metadata or settings the component will require when it is executed.  The name of the component that executes the action definition is identified using the component-name node.  The name is the name of a Java class that is dynamically loaded at runtime.  When referring to the built in Pentaho components, the fully qualified name of the component should not be used, just the class name. For example, use EmailComponent instead of org.pentaho.plugin.email.EmailComponent.

...

 

Action-inputs

...

The

...

action-inputs

...

and

...

action-resources

...

define

...

the

...

parameters

...

that

...

will

...

be

...

passed

...

into

...

the

...

component

...

when

...

it

...

executes.

...

  Some

...

components

...

have

...

required

...

inputs

...

that

...

must

...

be

...

available

...

or

...

runtime

...

error

...

will

...

occur.

...

  Some

...

inputs

...

may

...

be

...

specified

...

but

...

are

...

optional.

...

  For

...

example,

...

the

...

Email

...

Component

...

requires

...

a

...

to

...

but

...

the

...

cc

...

is

...

optional.

...

  There

...

are

...

several

...

ways

...

to

...

satisfy

...

a

...

required

...

input.

...

It

...

can

...

be

...

provided

...

as

...

a

...

passed

...

parameter

...

with

...

the

...

same

...

name

...

to

...

the

...

component.

...

It

...

can

...

be

...

mapped

...

to

...

a

...

different

...

name

...

and

...

passed

...

to

...

the

...

component.

...

It

...

can

...

be

...

hard

...

coded

...

with

...

a

...

constant

...

value

...

or

...

in

...

some

...

cases

...

it

...

could

...

be

...

prompted

...

for.

...

  By

...

default

...

the

...

email

...

component

...

should

...

have

...

an

...

action

...

input

...

that

...

looks

...

like:

...

Code Block
xml
xml
<action-inputs>
    <to type="string" />
          . . .
</action-inputs>
{code}

h2. Action Input Mapping

What happens if a component requires an input named *x* and I want to pass it a suitable parameter named *y*?&nbsp; You can map any action-input to a different name using the *mapping* attribute.&nbsp; Again, using our trusty Email Component example, let's assume we have a JavaScript rule that performs a query and returns the email address for a user in an output-parameter named *EMAIL*.&nbsp; Let's further assume that I want to use that parameter as the *to* parameter in the Email Component.&nbsp; The XML fragment would look like:
{code:xml}

Action Input Mapping

What happens if a component requires an input named x and I want to pass it a suitable parameter named y?  You can map any action-input to a different name using the mapping attribute.  Again, using our trusty Email Component example, let's assume we have a JavaScript rule that performs a query and returns the email address for a user in an output-parameter named EMAIL.  Let's further assume that I want to use that parameter as the to parameter in the Email Component.  The XML fragment would look like:

Code Block
xml
xml
<action-inputs>
    <to type="string" mapping="EMAIL"/>
                   . . .
</action-inputs>
{code}

h2. Constant Values as Inputs

If a component requires an input parameter and it is not found in the 

Constant Values as Inputs

If a component requires an input parameter and it is not found in the action-inputs,

...

the

...

component

...

will

...

automatically

...

look

...

for

...

an

...

XML

...

node

...

with

...

the

...

same

...

name,

...

in

...

the

...

component-definition

...

section.

...

  If

...

it

...

finds

...

one,

...

it

...

will

...

use

...

the

...

value

...

from

...

there.

...

  The

...

XML

...

fragment

...

would

...

look

...

like:

...

Code Block
xml
xml
<action-inputs>
</action-inputs>

<component-definition>
    <to>joe.pentaho@pentaho.org</to>
</component-definition>
{code}

h2. Replaceable Parameters

All components have the ability to use the built in template mechanism to perform text replacement using input parameters.&nbsp; This means that a constant value can be modified using the value of an action-input. Hmmm that wasn't very clear either.&nbsp; Let's try with an example:
{code:xml}

Replaceable Parameters

All components have the ability to use the built in template mechanism to perform text replacement using input parameters.  This means that a constant value can be modified using the value of an action-input. Hmmm that wasn't very clear either.  Let's try with an example:

Code Block
xml
xml
<action-inputs>
    <EMAIL type="string"/>
         . . .
</action-inputs>

<component-definition>
    <to>{EMAIL}@pentaho.org</to>
</component-definition>
{code}

The

...

text

...

within

...

the

...

curly

...

braces

...

{}

...

is

...

replaced

...

by

...

an

...

input

...

parameter

...

with

...

the

...

same

...

name.

...

  In

...

this

...

example,

...

if

...

the

...

value

...

of

...

the

...

action-input

...

EMAIL

...

is

...

joe.pentaho

...

then

...

the

...

value

...

of

...

the

...

to

...

parameter

...

passed

...

to

...

the

...

email

...

component

...

would

...

be

...

joe.pentaho@pentaho.org

...

.

...

:=TODO}
Note
title
TODO
Wiki Markup

Explain
{PREPARE:xxx}
and the date parameter.

h2. Prompting

Some components will generate a prompt for certain parameters that they require.&nbsp; The prompt will be generated by the runtime if the calling mechanism permits it.&nbsp; For example, the above mentioned Email Component requires a *to* parameter in order to know where to send the email.&nbsp; If the *to* parameter is specified as an action-input but it has a null value, the Email Component will ask the runtime if prompting is allowed.&nbsp; If the Action Sequence being executed has been launched from a web browser, the runtime will respond with *true* and the Email Component will ask the runtime to prompt the user for the *to* email address.&nbsp; If the Action Sequence was running via a web service call, the runtime would reply with *false* and the Email Component would generate a parameter not found error and return.

h2. Action-outputs

The *action-outputs* define what parameters will be saved in the Runtime Context and be made available to other Components when that component finishes executing.&nbsp; Like an *action-input*, an *action-output* can be mapped to another variable name using the mapping attribute.

h2. Component-definition

The *component-definition* node provides a place for any Component specific options or parameters.&nbsp;
{note:title=TODO}

Add

...

more

...

about

...

component-definition

...

and

...

action-outputs

...

Note

Wiki Markup
{scrollbar}