E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (69)
View Page History
...
h1. Features Before going further, it must be clear that no configuration for this component is intended to be created by hand.Neither by the Petals Studio.
And neither by the Petals Studio. In fact, only Talend Open Studio and Talend Integration Suite have the ability to generate a correct configuration for this component.
However, which one of these tool created the configuration is not important for this service-engine.
...When a request is received and started to be processed in the Petals-SE-Talend component, it is validated before being really processed.
The following list describes the order and the conditional steps in this validation process.
# If the validate-by-wsdl parameter is set to true, either in the component or in the service-unit, then the request is validated against the WSDL's schemas of the service-unit.
# If the validate-by-wsdl parameter is set to true, either in the component or in the service-unit, then the request is validated against the WSDL's schemas of the service-unit.
Here are the different steps involved in this validation process.
The first step is the WSDL-based validation of the request's XML payload.
If the *validate-exchange-by-wsdl* parameter is set to *true*, either in the component or in the service-unit, then the XML payload is validated against the WSDL of the service-unit.
The first step is the WSDL-based validation of the request's XML payload.
If the *validate-exchange-by-wsdl* parameter is set to *true*, either in the component or in the service-unit, then the XML payload is validated against the WSDL of the service-unit.
## If the validation fails, a fault is raised. Otherwise, the validation goes on.
{warning}
Be careful, WSDL-based validation does not work when the input message contains attachments.
## Be careful, WSDL-based validation does not work when the input message contains attachments. The Talend export for Petals does prevent that from happening.
Just remember it if you modify the jbi.xml by hand.
{warning}
The WSDL-based validation checks three elements:
# The called operation is defined in the service's WSDL.
# The called operation is associated with the called Message Excahnge Pattern (MEP).
# The XML payload is validated against the WSDL's XML schemas.
{warning}
{warning}
The WSDL-based validation checks three elements:
# The called operation is defined in the service's WSDL.
# The called operation is associated with the called Message Excahnge Pattern (MEP).
# The XML payload is validated against the WSDL's XML schemas.
{warning}
## Be careful, the current implementation of this feature makes disk access, thus reducing the performances.
# Then, there is a check made with respect to the singleton property of a job.
{warning}
The second and last step in the validation is a check about the singleton property of a job.
If a job is singleton, it means that only one instance of this job can be executed at once.
{info}
One typical example of a singleton job is a job which moves data from one database to another.
The second and last step in the validation is a check about the singleton property of a job.
If a job is singleton, it means that only one instance of this job can be executed at once.
{info}
One typical example of a singleton job is a job which moves data from one database to another.
If a job is singleton, it means that only one instance of this job can be executed at once. One typical example of a singleton job is a job which moves data from one database to another. It would make no sense for two instances of this job tor un at the same time, especially if they work on the same databases.
{info}
If the job is singleton and already running, then a fault is raised.
Otherwise, a new job instance is created. If the job is singleton, then the running state of this job is set to true and locked until it is this state is released (i.e. the job is executed).
{note}
The job creation strategy is a lazy strategy. A job instance is created on every received and validated message.
The consequence for singleton jobs is that all the messages sent to a singleton job while it is running will be rejected.
The job creation strategy is a lazy strategy. A job instance is created on every received and validated message.
The consequence for singleton jobs is that all the messages sent to a singleton job while it is running will be rejected.
{note}
...h2. Preparing the job's input
Once the request has been accepted, it is parsed to get the different possible parameters for a the job.
The message input contains up to 4 parts, that are described in the serivce's WSDL.
# The first parameters are the context parameters, child elements of the *contexts* element from the input message. These parameters will be passed to the job in its main method.
# Then, the data flow to be passed to a tPetalsIOnput instance is retrieved from the request. request. This data flow may not be present.
# The third kind of parameters is the input attachments.
## Each input attachments is serialized as a temporary file.
## Its location will be passed to the job through a context variable. This is why attachments are associated with context variables.
## Be careful, attachments are expected to be passed in MTOM mode. That is to say the attachment element has a grand-child element "xop:include" whose href attribute references an attachment.
## Besides, the name of the attachment element is the name of the context variable that will be associated with the temporary file location.
## Its location will be passed to the job through a context variable. This is why attachments are associated with context variables.
## Be careful, attachments are expected to be passed in MTOM mode. That is to say the attachment element has a grand-child element "xop:include" whose href attribute references an attachment.
## Besides, the name of the attachment element is the name of the context variable that will be associated with the temporary file location.
# Eventually, the component processes the native options to be passed to the job.
{note}
If a job does not support to be passed data flow (for a tPetalsInput), an entry is logged, but no fault is raised. The execution goes on normally.
{note}
Input attachments must respect some constraints:
{note}
Input attachments must respect some constraints:
As a user, you do not have to worry about this complexity. The configuration and the WSDL creation are made by the tools, during the export.
And the clients can be generated automatically from the WSDL.
And the clients can be generated automatically from the WSDL.
{note}
* Each input attachments is serialized as a temporary file.
* Its location will be passed to the job through a context variable. This is why attachments are associated with context variables.
* Be careful, attachments are expected to be passed in MTOM mode. That is to say the attachment element has a grand-child element "xop:include" whose href attribute references an attachment.
* Besides, the name of the attachment element is the name of the context variable that will be associated with the temporary file location.
* Its location will be passed to the job through a context variable. This is why attachments are associated with context variables.
* Be careful, attachments are expected to be passed in MTOM mode. That is to say the attachment element has a grand-child element "xop:include" whose href attribute references an attachment.
* Besides, the name of the attachment element is the name of the context variable that will be associated with the temporary file location.
{note} {info}
As a user, you do not have to worry about this appearing complexity.
The configuration and the WSDL creation are made by the tools, during the export.
And hopefully, clients to call such a service can be generated automatically from the WSDL.{info}
The configuration and the WSDL creation are made by the tools, during the export.
And hopefully, clients to call such a service can be generated automatically from the WSDL.{info}
If a job does not support to be passed data flow (for a tPetalsInput), an entry is logged, but no fault is raised. The execution goes on normally.
{note}
{note}
From one JBI message (an XML payload and attachments), the Petals-SE-Talend component gets at most 4 kind of parameters to pass to the jobs.
As you can see, from one JBI message (an XML payload and attachments), the Petals-SE-Talend component gets at most 4 kinds of parameter to pass to the jobs.
Three of them are merged together, since they are passed as contexts to the job. The remaining one concerns the tPetalsInput data.
Notice that the input message may not define any of these parameters. In this case, the component will pass nothing to the job.
Notice that the input message may not define any of these parameters. In this case, the component will pass nothing to the job.
{note}
In fact, the WSDL content and the expected parameters depend on the job's content and on the defined options during the export operation.
{note}
h2. Executing the job
At this point, the Petals-SE-Talend has built the job instance and prepared its parameter. the parameters.
If the job contains a tPetalsInput component, the data for this component is passed to the job.
The Talend contexts and options are then passed to the job and it is executed.
The Talend contexts and options are then passed to the job, right before its execution is launched.
...h2. Getting the job's output
The job's output is an array of array of String.
This result can contain only an integer, indicating the result of the job execution, or raw data (if the job has a tBufferOutput).
This result can contain only an integer, indicating the result of the job execution, or raw data (if the job has a tBufferOutput).
The native job's output is an array of array of String (String\[\]\[\]).
This result may contain only an integer (i.e. String\[ 0 \]\[ 0 \] is an integer), indicating the result of the job execution, or raw data (if the job has a tBufferOutput).
This result may contain only an integer (i.e. String\[ 0 \]\[ 0 \] is an integer), indicating the result of the job execution, or raw data (if the job has a tBufferOutput).
This is a way to determine whether the job execution succedded or not. The Petals-SE-Talend does not do it. It is the responsibility of the client to make this check (since in fact, it depends on the job itself).
...{note}
If a job does not support to be passed data flow (for a tPetalsInput) or asked data flow (for a tPetalsOutput), an entry is logged, but no fault is raised. The execution goes on normally.
{note}
Eventually, if it was specified during the job export that output attachments are to be expected after the job was executed, then they are taken back from the job.
Eventually, if it was specified during the job export that output attachments are to be expected after the job was executed, then they are taken back from the job.
These attachments must be passed from the job to the component through files. These files are then loaded by the component in memory and then, deleted from the disk.
The deletion of these files is not an option. Letting them on the disk could represent important risks. Indeed, a malicious client could override the context on each call, thus creating an infinite number of files on the disk. Unfinite until the disk crashes, obviously.
...{note}
If a component expects output attachments to be returned by the job, and that this job does not support it, then a fault is thrown. This can typically happen if you created your job with Talend Open Studio and exported a context as an "OUT-Attachment".
This can typically happen if you created your job with Talend Open Studio and exported a context as an "OUT-Attachment".
{note}
...* Expose a context as a parameter into the service's WSDL.
* Pass attachment files to a job.
* Pass attachment files to a job.
* Pass native parameters and options to a job.
* Get the job's execution result.
Other features are only supported by Talend Integration Suite.
Other features are only supported by Talend Integration Suite.
However, it is possible to use alternative ways, depending on the missing features. desired feature.
h2. Talend Integration Suite
In Talend Integration Suite, all the features of Talend Open Studio are supported. In fact, there are more.
It also embeds additional capabilities to work with Petals ESB.
* You can use tPetalsInput and tPetalsOutput components in your jobs.
** These components respectively allow you to pass data from Petals to the job and from the job to Petals.
** These components respectively allow you to pass data from Petals to the job and from the job to Petals.
** These two components do not have any specific parameters. They just need their schema to be defined.
* You can simulate the Petals behavior for these two components, meaning you can execute your job in Talend Integration Suite if it contains a tPetalsInput or a tPetalsOutput component.
** Thus, for a tPetalsInput, you can provide what would be the Petals input from a file that will be loaded before the simulation.
** Thus, for a tPetalsInput, you can provide what would be the Petals input from a file that will be loaded before the simulation.
...The export is the same in both Talend Open Studio and Talend Integration Suite.
The generated artifacts are the same in both of them. The And the content of the jbi.xml is the same in both of them.
The only differences are the job's content (which Talend components) and the generated WSDL (which depend on the job content and the export options).
The only differences are the job's content (which Talend components have been added into the job) and the generated WSDL (which depends on the job content and the export options).
The service-unit structure and the jbi.xml are desribed farther.
This section only introduces the export options, their impact on the result, while the next section describes the generated WSDL.
The generated WSDL is not discussed in this documentation.
Here is a snapshot version of the Talend export for Petals.
...| Jobs contexts | Select the context that will be used by default by the job. |
Eventually, there is the edition link to specify how contexts should be exposed in the. generated WSDL.
!SimpleJobExportContext1.jpg!
...When this link is clicked, a dialog shows up.
It lists all the job contexts, with their name, the type they will be associated with if exported, and the way they are exported.
It lists all the job contexts, with their name, the type they will be associated with if exported, and the way they are exported.
By default, no context is exported. Said differently, the export mode of for all the contexts is *Not exported*.
Here is a small description of the export modes.
|| Export Mode || Description ||
| Not exported | The context is not exported (not visible as a parameter). But the context can still be overridden using the native parameters (options) of the job. |
| Parameter | The context is exported as a parameter in the contexts. |
| In-Attachment | The context will be passed the location of a temporary file whose content was passed as an attachment attached in the input message. |
| Out-Attachment | The context will be read after the job was executed.
* This context must point to a file.
* This context must point to a file.
...* It will also be read after the job execution.
* The file will be deleted anyway.
* The file will be deleted anyway.
* The advantage of this export mode ifs to define the output file destination dynamically. |
h2. The WSDL structure for Talend service-units
h1.
h1. Component Configuration
...|| Parameter || Description || Default || Required ||
| validate-exchange-by-wsdl | True to validate the received messages with respect to the WSDL's schemas of the target service. \\
This parameter is also available in the configuration of the service-units. \\
Setting it in the component enables it for all the service-units deployed on this component. It also overrides the service-unit configuration for this parameter. \\
Setting it in the component enables it for all the service-units deployed on this component. It also overrides the service-unit configuration for this parameter. \\
...h2. Execute a Talend job when a message is received
The way the Petals-SE-Talend component processes a message ins described in the first section of this document.
...|| Parameter || Description || Default || Required ||
| name | The job's name \\ | \- | Yes |
| name | The job's name \\ | \- | Yes |
...{noformat}su-talend-JobName-provide.zip
+ META-INF
- jbi.xml
+ src
- { The source files }
- JobName.wsdl
- contexts.jar
- systemRoutines.jar
- userRoutines.jar
- JobName_JobVersion.jar
- JobDepenencies.jar (potentially, several JARs){noformat}
- jbi.xml
+ src
- { The source files }
- JobName.wsdl
- contexts.jar
- systemRoutines.jar
- userRoutines.jar
- JobName_JobVersion.jar
- JobDepenencies.jar (potentially, several JARs){noformat}
* META-INF
** jbi.xml
* src
** { source files }
* JobName.wsdl
* contexts.jar
* systemRoutines.jar
* userRoutines.jar
* JobName_JobVersion.jar
* JobDependencies.jar (there can be several jars){noformat}
** jbi.xml
* src
** { source files }
* JobName.wsdl
* contexts.jar
* systemRoutines.jar
* userRoutines.jar
* JobName_JobVersion.jar
* JobDependencies.jar (there can be several jars){noformat}
...