h2. Overall solution
The retained solution was to expose it through a web application, that would call the job exposed a web service. The interest of the web service resides in the fact that add-ons and load-balancing facilities could be added later on, without redeveloping everything. Associated to the Talend target, these elements led to choose Petals ESB.
Thus, Excel files will be uploaded to the web application, which will then send them as attachment to the job.
The response will contain the resulting XML file as an attachment. The web application will then provide a link to download this XML file.
h2. Petals Settings and Message Flows
!ArchiUC0.jpg!
*Deployed configurations:*
# One configuration for the Petals-SE-Talend, which embeds the job to execute. It exposes the job as a service inside Petals ESB.
# One configuration for the Petals-BC-SOAP component. It will expose the job as a Web Service outside Petals ESB.
*Message flows:*
If the web service is called from outside the bus, here are the different messages going through the bus.
# From Petals-BC-SOAP to Petals-SE-Talend: the input message.
# From Petals-SE-Talend to Petals-BC-SOAP: the response.
h1. Configuration for the Petals-SE-Talend component
h2. Creating the job
The job is made up of four Talend components:
* The *tFileInputExcel* component loads the Excel file.
* The *tMySqlInput* component retriives data from a MySQL database.
* The *tMap* component filters the data contained in the Excel file by using database fields. It also performs some esthetic corrections.
* Eventually, the *tFileOutputXML* component serializes the result as an XML file.
\\
Here is what the job looks like.
!ExcelJob.jpg!
\\
Both kinds of files, as well as the database, deals with customers data.
Here are the different schemas, starting with the Excel one.
!SchemaExcel.jpg!
\\
Here is the schema of the MySQL database.
!SchemaDatabase.jpg!
\\
And here is the schema of the output XML.
!SchemaXml.jpg!
Roughly, the differences between the input and the output consist in merging the name and only keeping the clients whose revenue are over 50 K€.
\\
The main configuration points for the tFileInputExcel and tFileOutputXML rely on the fact this job will take attachment files in input and return attached files in output.
This why the location of the XML and Excel files must be defined in two different context variables (respectively _inLocation_, _outLocation_).
Besides, _outLocation_ will be have to be fixed by the client (the web application). This will be mentioned again during the export.
\\
The configuration for the tMySsqlInput is not given here, since it is very standard.
And here is a screen shot of the tMap editor, showing the mapping of the inputs to the output.
!ExcelMapEditor.jpg!
h2. Exporting the job for Petals
The job is exported as a singleton job. The reason is that the output location will be the same on every call.
In the scope of possible extensions, the Petals end-point will be generated by Petals on deployment. Thus, to deploy a new instance of this job inside Petals, there is no need to edit the or reexport the job. You can use the same deployment archive and install it directly.
Also, export the context variable _inLocation_ as an *In-Attachment*.
And export the context variable _outLocation_ as a *Parameter and Out-Attachment*.
Here is the export dialog.
!ExcelExport.jpg!
h1. Configuration for the Petals-BC-SOAP component
The creation of a SOAP configuration is generally fairly simple using the Petals Studio.
The goal here is to create a configuration for the Petals SOAP component, that will consume the Talend service.
It means every call this configuration will handle will be forwarded to the consumed service.
{info}
Please, make sure to use at least the version 4.0.3 of the Petals-BC-SOAP.
Previous versions did not manage MTOM attachments (in input and in output) correctly.
{info}
\\
Since we expect a response, we will call the service with the *InOut* pattern.
Looking at the WSDL, we can also see that only the operation *executJob* is associated with this MEP.
Therefore, it will be the called operation.
\\
Eventually, since we let the end-point be generated by Petals, we do not have to specify an end-point for the service to consume.
In fact, the interface name will be enough. Petals will decide which end-point must be called for this interface.
\\
Here is the jbi.xml for the configuration.
{code:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>
<!--
JBI descriptor for the Petals' "petals-bc-soap" component (SOAP).
Originally created for the version 4.0 of the component.
-->
<jbi:jbi version="1.0"
xmlns:interfaceNs="http://petals.ow2.org/talend/"
xmlns:jbi="http://java.sun.com/xml/ns/jbi"
xmlns:petalsCDK="http://petals.ow2.org/components/extensions/version-5"
xmlns:soap="http://petals.ow2.org/components/soap/version-4"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- Import a Service into Petals or Expose a Petals Service => use a BC. -->
<jbi:services binding-component="true">
<!-- Expose a Petals Service => consumes a Service. -->
<jbi:consumes
interface-name="interfaceNs:Customers_3ServicePortType">
<!-- CDK specific elements -->
<petalsCDK:timeout>30000</petalsCDK:timeout>
<petalsCDK:operation xmlns:op="http://petals.ow2.org/talend/">op:executeJob</petalsCDK:operation>
<petalsCDK:mep>InOut</petalsCDK:mep>
<!-- Component specific elements -->
<soap:address>Customers</soap:address>
<soap:remove-root>false</soap:remove-root>
<soap:mode>SOAP</soap:mode>
<soap:rest-add-namespace-prefix>soapbc</soap:rest-add-namespace-prefix>
<soap:enable-http-transport>true</soap:enable-http-transport>
<soap:enable-jms-transport>true</soap:enable-jms-transport>
</jbi:consumes>
</jbi:services>
</jbi:jbi>
{code}
h1. Running the use case
To test this use case, you need to deploy the Petals-SE-Talend and Petals-BC-SOAP components in Petals.
E-mail
...