...
{section}
{column}
h1. Preliminary notes
This use case can only be reproduced with Talend Integration Suite.
People using Talend Open Studio can find an alternative in the use case "Data Flow - From Petals to a job using attachments".
{column}
{column:width=360px}
{panel}{toc}{panel}
{column}{section}
h1. Rationale
Send a data flow from Petals into a Talend job, that will insert these data into a database.
In the scope of this use case, we could imagine, even if it is not shown, that these data are transformed before being inserted.
The input message provides the data flow.
Only the job's result is expected in the response.
h1. Creating and exporting the job
The job to be executed performs the following actions:
# The job is passed the data flow coming from Petals.
# The job connects to a database and writes the data flow in this database. If the target table does not exist, it is created.
This job has no context variable.
...
\\
{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 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 two 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_2.jpg!
\\
Here is the schema of the tPetalsInput component.
!PetalsToJob_tpi_tpischema_2.jpg!
\\
Here is the schema of the tMySqlOutput tPetalsInput component.
!PetalsToJob_tpi_msoschema_2.jpg!
\\
Here And here are the properties of the tPetalsInput component.
!PetalsToJob_tpi_msoproperties_2.jpg!
\\
Eventually, here is the schema and the transformation editor of the tMap component.
!PetalsToJob_tpi_tmaped2.jpg|thumbnail!
h2. Exporting the job
...
Select the job and right-click it. Select *Export to Petals ESB*.
Update the target destination.
Let the job be exposed as a singleton.
You should have the following dialog:
!PetalsToJob_tpi_export.jpg!
Click *Finish*.
h1. Deploying and testing in Petals
h2. Looking at the generated WSDL
In the created Petals service assembly, the most interesting thing to look at is the WSDL.
Indeed, the WSDL will determine the way the exported service will be called.
\\
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">
<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="id" type="xs:integer" /> <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}
\\
{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}
h2. Deploying and testing this new service
To test this service, you can use a tool like SoapUI.
This way, you can see what the XML messages look like.
The first thing to do is to create a service-unit for the Petals-BC-SOAP component, that exposes (consumes) our _Talend job as a service_ outside the bus.
This step is not described here. You can take a look at the Petals-BC-SOAP documentation and the Petals Studio documentation.
Just make sure the SOAP configuration uses the InOut MEP.
\\
Now, your input message (in SoapUI) should look like this:
{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/>
<!--Optional:-->
<tal:in-attachments/>
<!--Zero or more repetitions:-->
<tal:in-data-bean>
<tal:id>0</tal:id>
<tal:name>Roger</tal:name>
<tal:address>17, rue de la république</tal:address>
<tal:registerTime>0</tal:registerTime>
</tal:in-data-bean>
<tal:in-data-bean>
<tal:id>1</tal:id>
<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 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-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.
\\
The returned message, when everything works, is:
{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>
</soapenv:Envelope>
{code}
\\
If the job execution fails, the 0 is replaced by another integer, e.g. 1.
One failure reason can be, as an example, that the database is not started.
Job errors generally result in an exception being displayed into the Petals console.
To Otherwise, to determine the act cause of a problem, you would have to use logging features available in the Talend palet.
However, let's make it clear, the job's logs are managed independently of Petals and its monitoring capabilities.
E-mail