|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (30)
View Page History{section}
{column}
{column}
h1. Preliminary notes
This use case can be reproduced with both Talend Open Studio and Talend Integration Suite.
This use case can only be reproduced with Talend Integration Suite.
It is an alternative way to undertake what is done in the use cases "Data Flow - From a job to Petals using a tPetalsOutput" and "Data Flow - From a job to Petals using a tBufferOutput".
{column}
{column:width=360px}
{panel}{toc}{panel}
{column}{section}
{column:width=360px}
{panel}{toc}{panel}
{column}{section}
h1. Rationale
Execute a Talend job into Petals and passing it a context as a parameter described in the service's WSDL interface.
The resulting file will be returned as an attachement
The resulting file will be returned as an attachement
Generate a data flow in a job, write it into a file and send this file as an attachment inside Petals.
The job is exposed as a service into Petals. When this service is called, the parameter is passed to the job, which is then executed.
The file created by this job is then returned as an attchment.
The file created by this job is then returned as an attchment.
The input message provides the value of of the context which is exposed as a parameter in the service's interface.
Only the job's result is expected in the response.
Only the job's result is expected in the response.
The input message provides nothing.
The job's result and an attachment file are expected in the response.
The job's result and an attachment file are expected in the response.
h1. Creating and exporting the job
The job to be executed performs the following actions:
# The job is passed the value of the context variable.
# 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.
# 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.
# The job generates a data flow.
# This data flow is written into a file, as an XML document (it could also be any kind of file, e.g. CSV, positional...).
# This file is loaded and attached to the returned message.
# This data flow is written into a file, as an XML document (it could also be any kind of file, e.g. CSV, positional...).
# This file is loaded and attached to the returned message.
This job has one context variable, which indicates the location of the CSV file to load and attach.
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.
Remember, this file will be deleted once it has been loaded.
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 two columns named "CustomerName" and CustomerAddress, both being of type varchar(255).
h2. Creating the job
The job creation is detailled in the use case "A Simple Talend Job".
There is no difference.
There is no difference.
The job is made up of two components:
# The tRowGenerator generates the data flow.
# The tFileOutputXML serializes the data flow as an XML file. The file location is defined by a context variable (of type String).
# The tRowGenerator generates the data flow.
# The tFileOutputXML serializes the data flow as an XML file. The file location is defined by a context variable (of type String).
Here is the overall aspect of the job.
!JobToPetals_file_job.jpg!
\\
Here is the schema and the generation settings for the tRowGenerator component.
!JobToPetals_buf_trgschema.jpg!
\\
Here are the properties of the tFileOutputXML component.
It has the same schema than the tRowGenerator.
!JobToPetals_file_xmlproperties.jpg!
!JobToPetals_file_job.jpg!
\\
Here is the schema and the generation settings for the tRowGenerator component.
!JobToPetals_buf_trgschema.jpg!
\\
Here are the properties of the tFileOutputXML component.
It has the same schema than the tRowGenerator.
!JobToPetals_file_xmlproperties.jpg!
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.
Update the target destination.
Let the job be exposed as a singleton.
Click *Edit the exported contexts* to export the file location context.
In the export mode, select *OUT-Attachment* or *Parameter and OUT-Attachment*.
In the scope of this use case, we use *OUT-Attachment*.
Consequently, the file location is the default one, defined in the job.
You should have the following dialog:
!JobToPetals_file_export.jpg!
Click *Finish*.
In the export mode, select *OUT-Attachment* or *Parameter and OUT-Attachment*.
In the scope of this use case, we use *OUT-Attachment*.
Consequently, the file location is the default one, defined in the job.
You should have the following dialog:
!JobToPetals_file_export.jpg!
Click *Finish*.
h1. Deploying and testing in Petals
h2. Looking at the created archive generated WSDL
The created archive is a Petals service assembly.
More details are available in the documentation of the petals-SE-Talend.
More details are available in the documentation of the petals-SE-Talend.
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.
Indeed, the WSDL will determine the way the exported service will be called.
What must be taken care of is the jbi.xml and the WSDL files available in the service-unit.
If you open the created archive, it contains another archive. This second archive contains a jbi.xml file.
If you open the created archive, it contains another archive. This second archive contains a jbi.xml file.
\\
The input message's description expects no parameter.
The input message's description expects no parameter.
The WSDL file exposes no parameter.
The possible input parameters are:
The possible input parameters are:
{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: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:sequence>
</xs:complexType>
{code}
\\
And the output message includes the job's result and the attached file.
{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:element name="outputLocation" nillable="true" type="tns:attachment" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="outRow">
<xs:sequence>
</xs:sequence>
</xs:complexType>
{code}
\\
As you can see, the WSDL generation has taken into account the exported context.
<xs:sequence>
</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}
\\
And the output message includes the job's result and the attached file.
{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:element name="outputLocation" nillable="true" type="tns:attachment" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="outRow">
<xs:sequence>
</xs:sequence>
</xs:complexType>
{code}
\\
As you can see, the WSDL generation has taken into account the exported context.
h2. Deploying and testing this new service
SoapUI is used for this test...
Since we use attachments, we will prefer using a Java client instead of SoapUI.
However, it is possible to use SoapUI to send or receive messages with attachments. Just make sure the MTOM property is activated.
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.
Then, to generate a client from the WSDL, you can use Apache CXF or Axis2.
In the scope of this use case, Apache CXF is used. Only the client class is shown here.
\\
The client's code is the following:
{code:lang=java}
TODO
{code}
\\
Notice that the MTOM-mode was activated. Not enabling it will result in errors.
\\
The execution output is:
{panel}
{panel}
\\
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.
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.
However, it is possible to use SoapUI to send or receive messages with attachments. Just make sure the MTOM property is activated.
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.
Then, to generate a client from the WSDL, you can use Apache CXF or Axis2.
In the scope of this use case, Apache CXF is used. Only the client class is shown here.
\\
The client's code is the following:
{code:lang=java}
TODO
{code}
\\
Notice that the MTOM-mode was activated. Not enabling it will result in errors.
\\
The execution output is:
{panel}
{panel}
\\
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.
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.