The Tasklet IO Configuration interface allows a user to configure how Tasklets can communicate with each other when a Job is run. A Job that is composed of multiple Tasklets, can configure the Tasklets to communicate with each other when the Job is run. A Tasklet has the option of exposing properties via its output JavaBean that can then be passed to other Tasklets that execute after it in the Job workflow chain. These output properties from one Tasklet can be passed to the input JavaBean properties of other Tasklets. The result of this is that the output of one Tasklet (source Tasklets) functions as the input to another Tasklet (target Tasklet). And you can do all this with no programming - just point and click to map one output property from a given Tasklet to a corresponding input property of another Tasklet.
If a Tasklet does not wish to communicate with other Tasklets, then you will not need to use this feature. But the power of building components really comes into play when you can get components (Tasklets), that have no prior knowledge of each other, to be able to collaborate by passing information between each other using this simple point and click interface.
A user, using this GUI, can pick and choose which output properties map to which input properties for each pair of Tasklets in a Job. There are restrictions in how the output/input mappings can work, especially when the output/input property types are not identical (for example, map a long to an int type). The individual property types must be compatible based on what is referred to as "widening conversion rules". The GUI automatically takes care of deciding which output/input properties are compatible, between a particular source Tasklet and target Tasklet, so the user does not need to deal with it directly. So you can map an int value to a long value, but you can't map a long value to an int value. But you can for example map a long value to a String or StringBuffer, for example.
Step 1: Select the Target Tasklet
By default the target Tasklet will be the one you click the "I/O" button on in the "Configure Job Workflow" UI, but you can make any of the Tasklets in the Job workflow chain the target Tasklet. The target Tasklet is the Tasklet that will have properties mapped to it and copied into its input JavaBean.
Step 2: Choose Which Tasklets To Source Properties From
By default no source Tasklets are specified. Choose which Tasklets you want to pull properties from in order to pass to the target Tasklet. You can choose one or more source Tasklets. Note that only Tasklets that run before the target Tasklet are eligable to be source Tasklets. Click the "Apply Selection Changes" button to select the source Tasklets you want as input for your target Tasklet.
Step 3: Map Source Properties to Target Properties
Now you are ready to choose which source properties you want to be passed to the target Tasklet. Note, that only source properties that are compatible with the given target property will be shown. Once you are done you will be ready to go. Your job will now, when run, pass the specified source properties from each configured source Tasklet to the specified properties of the target Tasklet.
For a simple example, let's imagine a job with two Tasklets. We will describe how these two
Tasklets can pass properties to each other when the job is run. The first Tasklet is called "Money",
and it calculates the amount of money the company has made that day and saves it in its output JavaBean property
profit which is of Java type
int. Now the second Tasklet is a simple
Tasklet called "EmailAlert" that just sends emails. All it knows how to do is just send emails
to the company's CFO. Now
we want this job to calculate the company's profit and then send this information in an email to the
CFO. The "EmailAlert" has an exposed input JavaBean property called bodyText and is of Java type
String that is used as the body of the email alert that is sent to the CFO. Now if we
map the profit property (of type int) in the Money Tasklet to the bodyText property (of type String)
in the EmailAlert Tasklet we can make these two Tasklets work together to accomplish our goal. As you can
imagine these two Tasklets where not designed to work together but can be made to complement each other. Notice
how the profit property is of type int but can still be passed to the bodyText property that is of type
String. This is possible because this is considered a "widening conversion". For example, the
reverse situation of mapping/converting
a String to an int would not be allowed because it is considered to be a narrowing conversion. Again
the user does not have to worry about this. The tool only permits you to map the properties that are
Normally you will be mapping one source property (of a source Tasklet's output JavaBean) to a single target property (of a target Tasklet's input JavaBean). If the property types are of the same Java type the mapping will be allowed naturally, however, if they are not of the same type, the mapping can still occur, if the types are compatible based on the "widening conversion rules" as defined by the SOAFaces specification (described below).
A one to one mapping between source and target is the simple case. Now another powerful feature of SOAFaces property mapping is that it allows multiple source properties to be mapped to a single target property. This can allow multiple source Tasklets to pass properties to a single target Tasklet's property. This can be used to allow multiple Tasklets, for example, to send multiple email addresses to a single Tasklet email alert Tasklet (where the alert address property is a String array). It is really up to the Tasklet developer to implement the setter method of the target property's input JavaBean method such that it aggregates/appends into the target input JavaBean property, thus allowing the appending of multiple Strings in this case from multiple source Tasklet properties.
The widening conversions rules described in this section detail how to map an output JavaBean property to an input JavaBean property when the properties are not of the exact same Java type. Narrowing conversions are not allowed. So for example, this means that going from an Integer Java type to a Short Java type is not allowed, because an Integer would have to be "narrowed" to be mapped to a Short. This would cause information to be lost and thus is not allowed. The reverse is allowed, because a Short when converted to an Integer is considered a widening conversion and no information is lost in the conversion.
Two general forms of data conversion are possible between an output JavaBean property and input JavaBean property when widening conversion occurs:1) Java Core Reflection Data Conversion Spec (basic widening conversion as defined by the Java spec)
The Extended conversion is allowed when the target Tasklet's input JavaBean property is a String/StringBuffer. Given that all Java Objects support the toString() method, any object can be converted and mapped to a String or StringBuffer. Primitive types are also mapped to String or StringBuffer by first wrapping them into corresponding objects. The Extended conversion rules are considered a form of "widening" conversion. Thus converting any Object to a String or StringBuffer is considered permissible.
Special Array Mapping Rules:
There are some special rules to consider when dealing with Java Arrays. These rules pertain to the use of Arrays in either an output JavaBean and/or input JavaBean. Arrays allow for some special behavior when mapping occurs. There are three types of output JavaBean to input JavaBean mapping rules to consider for this situation:
Input JavaBean Considerations:
If a BeanInfo object exists for an input JavaBean, it will be used during the mapping processes between Tasklets to determine which input JavaBean properties are exposed for mapping. The developer can use this to control what input JavaBean properties are exposed for mapping from other Tasklets. By defining a BeanInfo class for the input JavaBean, this allows the Tasklet developer to control what JavaBean properties are exposed to other Tasklets and which are not exposed. If a BeanInfo object is not available for an input JavaBean, then only properties with public setter/getter methods will be exposed for mapping between Tasklets.
Output JavaBean Considerations:
BeanInfo objects will not be used in the case of the source Tasklets output JavaBean. Output JaaBeans are only reflected to find their getter methods/properties. All properties with getter methods are available as source input JavaBean properties for other target Tasklets.