Petals-SE-Talend

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (34)

View Page History
{section}
{column}

h1. Features

Before going further, it must be clear that no configuration for this component is intended to be created by hand.Neither by the Petals Studio.
In fact, only Talend Open Studio and Talend Integration Suite have the ability to generate a correct configuration for this component.
{column}
{column:width=300px}
{panel}{toc}{panel}
{column}{section}





h1. The way it works

{warning}

\\
The WSDL-based validation checks three elements:
# The called operation is defined in the service's WSDL.
{warning}

\\
The second and last step in the validation is a check about the singleton property of a job.
If a job is singleton, it means that only one instance of this job can be executed at once.
Otherwise, a new job instance is created. If the job is singleton, then the running state of this job is set to true and locked until it is this state is released (i.e. the job is executed).

\\
{note}

If a job does not support to be passed data flow (for a tPetalsInput), an entry is logged, but no fault is raised. The execution goes on normally.
{note}

\\
Input attachments must respect some constraints:



* Each input attachments is serialized as a temporary file.
* Its location will be passed to the job through a context variable. This is why attachments are associated with context variables.


\\


As you can see, from one JBI message (an XML payload and attachments), the Petals-SE-Talend component gets at most 4 kinds of parameter to pass to the jobs.
Three of them are merged together, since they are passed as contexts to the job. The remaining one concerns the tPetalsInput data.
h2. Getting the job's output

The native job's output is an array of array of String (String\[\]\[\]).
This result may contain only an integer (i.e. String\[ 0 \]\[ 0 \] is an integer), indicating the result of the job execution, or raw data (if the job has a tBufferOutput).
The native job's output is an array of array of String, that is to say: {code:lang=java}String[][]{code}
This result may contain only an integer, in which case {code:lang=java}String[ 0 ][ 0 ]{code} is an integer and indicates the result of the job execution. Or, this array contains raw data (which is the case if the job contains a tBufferOutput).
This is can be a way solution to determine whether the job execution succedded or not. The Petals-SE-Talend does not do it. It is the responsibility of the client to make this check (since in fact, it depends on the job itself).

If the job contained a tPetalsOutput, then the output data flow is retreived from the job.
{note}

\\
Eventually, if it was specified during the job export that output attachments are to be expected after the job was executed, then they are taken back from the job.
These attachments must be passed from the job to the component through files. These files are loaded by the component in memory and then, deleted from the disk.
Now that everything has been gathered from the job, the response can be built and returned.
Hence, the response can count up to 3 parts:
# The job's result (String\[\]\[\]). (remember, the array of array of String). This part is always returned.
# The output data beans, if the job contained a tPetalsOutput.
# The output attachments.
| Jobs contexts | Select the context that will be used by default by the job. |

\\
Eventually, there is the edition link to specify how contexts should be exposed in the generated WSDL.

By default, no context is exported. Said differently, the export mode for all the contexts is *Not exported*.

\\
Here is a small description of the export modes.



\\
The component configuration includes the configuration of the CDK. The following parameters correspond to the CDK configuration.
{include:0 CDK Component Configuration Table}
This component also has one specific configuration parameter.

\\
This component also has one specific configuration parameter.
|| Parameter || Description || Default || Required ||
| validate-exchange-by-wsdl | True to validate the received messages with respect to the WSDL of the target service. \\ |

This parameter is also available in the configuration of the service-units. \\
Setting it in the component enables it for all the service-units deployed on this component. It also overrides the service-unit configuration for this parameter. \\
\\
Setting it in the component enables it for all the service-units deployed on this component. It also overrides the service-unit configuration for this parameter.
\\
\\
Beware, for the moment, WSDL-based validation does not work with messages having attachments. | \| false | \| false | \|

\\
{warning}
The Petals-SE-Talend component can only handle messages coming from inside the bus. Therefore, you cannot specify an external-listener class-name.{warning}
h2. Service Unit descriptor

The Service Unit descriptor file ( jbi.xml ) looks like this :
{code:lang=xml}<!-- Remember, this file is intended to be generated by Talend Open Studio or Talend Integration Suite -->
<?xml version="1.0" encoding="UTF-8"?>

*Configuration of a Service Unit to expose a Talend job as a service into Petals ESB :*
{table-plus}












|| Parameter || Description || Default || Required ||
| name | The job's name \\ | \- | Yes |
| output-attachment \\ | The name of a context variable that points to a file that must be attached to the returned message. \\
The cardinality for this element is 0-*. \\ | \- | No \\ |
{table-plus}

\\
{include:0 CDK SU Provide Configuration}
\\
By default, a WSDL is generated during the Talend export for Petals.

\\
The directory structure of a SU for the Petals-SE-Talend looks like this:

* JobName_JobVersion.jar
* JobDependencies.jar (there can be several jars){noformat}


h1.