Data Flow - From Petals to a Job using a tPetalsInput

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

Changes (30)

View Page History
{info}
In the scope of this use case, it is assumed there is a database *formationtalend* on the localhost, having a table named *customers*.
The schema of the *customers* table includes two columns named *CustomerName* and *CustomerAddress*, both being of type varchar(255).
The schema of the *customers* table includes three columns named *CustomerName* (varchar(255)), *CustomerAddress* (varchar(255)) and *RegisterTime* (varchar(50)).
{info}

h2. Creating the job

The job is made up of three components:
# The tPetalsInput transforms the Petals' data flow into a Talend flow.
# The tMap transforms the Petals input into data that can be directly inserted into the database.
# The tMySqlOutput writes the data into the database.

Here is the overall aspect of the job.
!PetalsToJob_tpi_job.jpg|border=1!

\\
Here is the schema of the tPetalsInput component.

!PetalsToJob_tpi_tpischema.jpg!

\\
Here is the schema of the tMySqlOutput component.

!PetalsToJob_tpi_msoschema.jpg!

\\
Here are the properties of the tPetalsInput component.

!PetalsToJob_tpi_msoproperties.jpg!

\\
Eventually, here is the schema and the transformation editor of the tMap component.

!PetalsToJob_tpi_tmaped2.jpg|thumbnail!



h2. Exporting the job

Let the job be exposed as a singleton.

Click *Edit the exposed contexts*.
A dialog shows up. Export the _outputLocation_ context as an *Out-Attachment*.

You should have the following dialog:

!PetalsToJob_tpi_export.jpg!



Click the *Export mode* column, and select *Parameter* in the combo box. Click *OK*.
The link label should be updated and indicate the number of exported contexts.



Click *Finish*.


\\
The input message's description requires empty parameters.
The input message's description only expects the data for the tPetalsInput component.
The WSDL generation has taken into account the schema of the tPetalsInput.

{code:lang=xml}
<xs:element name="executeJob" type="tns:executeJob" />
<xs:complexType name="executeJob">
<xs:sequence>
<xs:element minOccurs="0" name="contexts" type="tns:talendContexts" />
<xs:element minOccurs="0" name="in-attachments" type="tns:inAttachments" />
<xs:element maxOccurs="unbounded" minOccurs="0" name="in-data-bean" type="tns:inRow" />
<xs:element maxOccurs="unbounded" minOccurs="0" name="talend-option" type="xs:string" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="talendContexts">
{code} <xs:sequence>
</xs:sequence>
</xs:complexType>

<xs:complexType name="inAttachments">
<xs:sequence>
</xs:sequence>
</xs:complexType>

<xs:complexType name="inRow">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="address" type="xs:string" nillable="true" />
<xs:element name="registerTime" type="xs:long" nillable="true" />
</xs:sequence>
</xs:complexType>
{code}
\\
And the output message includes the job's result and the output attachment.
{tip}
Notice that the Java *Date* type is expected to be given as a *timestamp* (long). The date pattern is defined and applied in the job.
{tip}

\\
And the output message only includes the job's result.

{code:lang=xml}
<xs:element name="executeJobResponse" type="tns:executeJobResponse" />
<xs:complexType name="executeJobResponse">
<xs:sequence>
<xs:element minOccurs="0" name="talend-job-output" type="tns:talendJobOutput" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="talendJobOutput">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="executionResult" nillable="true" type="ns1:stringArray" />
<xs:element minOccurs="0" name="outAttachment" type="tns:outAttachments" />
<xs:element maxOccurs="unbounded" minOccurs="0" name="outDataBean" nillable="true" type="tns:outRow" />
</xs:sequence>
</xs:complexType>

<xs:complexType name="outAttachments">
<xs:sequence>
</xs:sequence>
</xs:complexType>

<xs:complexType name="outRow">
<xs:sequence>
</xs:sequence>
</xs:complexType>
{code}


{code:lang=xml}
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tal="http://petals.ow2.org/talend/">
<soapenv:Header/>
<soapenv:Body>
<tal:executeJob>
<!--Optional:-->
<tal:contexts/>
TODO
<!--Optional:-->
<tal:in-attachments/>

<!--Zero or more repetitions:-->
<tal:in-data-bean>
<tal:name>Roger</tal:name>
<tal:address>17, rue dela république</tal:address>
<tal:registerTime>0</tal:registerTime>
</tal:in-data-bean>
<tal:in-data-bean>
<tal:name>Louis</tal:name>
<tal:address>1, avenue H. de Balzac</tal:address>
<tal:registerTime>175486231</tal:registerTime>
</tal:in-data-bean>

<!--Zero or more repetitions:-->
<tal:talend-option>?</tal:talend-option>
</tal:executeJob>
</soapenv:Body>
</soapenv:Envelope>
{code}

\\
Notice the XML shape.
The in-data-rows list of _in-data-bean_ will be passed in raw mode to the job, and loaded into the job's flow by the tPetalsInput component.
Every in-data-row _in-data-bean_ has the same list of children, each child being a column in the schema of the tPetalsInput.

Thus, the expected data schema is defined by the job, and not by the service's contract.
In fact, the service's contract is partially generated from this schema.
As said in the other use cases, it is the job's content which define what the service contract will be.


{code:lang=xml}
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<tns:executeJobResponse xmlns:tns="http://petals.ow2.org/talend/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns:talend-job-output>
<tns:executionResult>
<jaxb:item xmlns:jaxb="http://jaxb.dev.java.net/array">0</jaxb:item>
</tns:executionResult>
<tns:outAttachment/>
</tns:talend-job-output>
</tns:executeJobResponse>
</soapenv:Body>
TODO </soapenv:Envelope>
{code}
\\