{section}
{column}

h1. Preliminary notes

This use case can only be reproduced with Talend Integration Suite.
This use case relies on the use case "A Simple Talend Job".
{column}
{column:width=360px}
{panel}{toc}{panel}
{column}{section}

h1. Rationale

Execute a Talend job into Petals, whose resulting file will be returned as an attachement.
The job is exposed as a service into Petals. When this service is called, it is executed. The file created by this job is then returned as an attchment.


The input message provides no information.
The response is made up of two parts:
* The job's result (an array of array of String).
* The created file, as an output attachment.

h1. Creating and exporting the job

The job to be executed performs the following actions:
# The job connects to a database.
# It retrieves the content of a table.
# It serializes part of the extracted data as a CSV file on the disk.
# Once the execution terminated, the created file is attached to the returned message.

This job has one context variable, which indicates the location of the CSV file.
This location will be read by the Petals-SE-Talend component once the execution is terminated. The file will then be attached to the returned message.

\\
{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).
{info}



h2. Creating the job

The job export is detailled in the use case "A Simple Talend Job".
There is no difference.


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.

Click *Edit the exposed contexts*.

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.

!SimpleJobExportContext2.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 requires empty parameters.

{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="inAttachments">
<xs:sequence>
</xs:sequence>
</xs:complexType>

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

{code}

\\
As you can see, the context name, type and default value have been exported in the generated WSDL.
In any case, the default value is more useful to document the service than for the execution.

{note}
Obviously, the file path example to illustrate a context may not be the best one.
Anyway, it serves its purpose, which is being an example.
{note}

<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: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>

{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}
TODO
{code}

\\
Notice that there are only empty parameters.


\\
The returned message, when everything works, is:

{code:lang=xml}
TODO
{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.

\\
Here are the first lines if this file (the database was populated with random values from another Talend job - do not be shocked by the values).

{panel}

TODO: detail the output attachment

{panel}