Difference between revisions of "Adapters-HowTo"
(Created page with "This is intended as a mini guide for a developer who wants to create a new adapter for {{GVESB}}. == Plugin and Adapter == == Interfaces: call enqueue e dequeue == == Con...") |
|||
| (12 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
| − | == | + | == Adapter == |
| − | + | An adapter gives {{GVESB}} the ability to communicate with external systems. | |
| − | + | Such systems can have their own protocol, language, APIs, services, etc. , and the adapter has to behave like an interface and integrate the external system's functionalities into {{GVESB}}. | |
| − | + | An adapter is not tied to any particular structure or architecture, it can be implemented as desired, apart from the fact that it must use an interface (like described below) and receive/return a [[GVBuffer]]. | |
| − | |||
| − | |||
| − | |||
== Configuration Files == | == Configuration Files == | ||
| + | == Interfaces methods == | ||
| + | The Operation interface has to be implemented each time a new GVVCL object is designed to make a call to an external system. | ||
| + | The Node passed to the init() method is the one that we can find in the GVAdapters.xml configuration file. Each time you create an adapter you will add a section (node) into such file, like, for example: | ||
| + | <syntaxhighlight lang="xml"> | ||
| + | <GVDataHandlerConfiguration name="DH_ENGINE" type="module" version="1.0"> | ||
| + | </syntaxhighlight> | ||
| + | for the [[DataHandler]]. | ||
| + | The Operation interface has three subinterfaces: CallOperation, [[VCLEnqueueOperation|EnqueueOperation]] and [[VCLDequeueOperation|DequeueOperation]], all defined into it.greenvulcano.gvesb.virtual package. The first one represents a syncronous call, the last two are used when dealing with queues. The main method of these interfaces is perform(), that accepts a GVBuffer as input and returns the same GVBuffer as output. | ||
| − | + | '''Please note:''' When implementing a new adapter it's important not to create a new [[GVBuffer]] but to output data into the received one. | |
| − | + | The buffer contains the input/output data for all the workflow operations, thus the output has to be ''added'' into the buffer so that the [[Core]] is | |
| + | able to know the status and data of each operation, reporting on it and reproducing it in case of need. | ||
Latest revision as of 13:14, 21 December 2012
This is intended as a mini guide for a developer who wants to create a new adapter for GreenVulcano® ESB.
Adapter
An adapter gives GreenVulcano® ESB the ability to communicate with external systems. Such systems can have their own protocol, language, APIs, services, etc. , and the adapter has to behave like an interface and integrate the external system's functionalities into GreenVulcano® ESB. An adapter is not tied to any particular structure or architecture, it can be implemented as desired, apart from the fact that it must use an interface (like described below) and receive/return a GVBuffer.
Configuration Files
Interfaces methods
The Operation interface has to be implemented each time a new GVVCL object is designed to make a call to an external system. The Node passed to the init() method is the one that we can find in the GVAdapters.xml configuration file. Each time you create an adapter you will add a section (node) into such file, like, for example:
<GVDataHandlerConfiguration name="DH_ENGINE" type="module" version="1.0">
for the DataHandler. The Operation interface has three subinterfaces: CallOperation, EnqueueOperation and DequeueOperation, all defined into it.greenvulcano.gvesb.virtual package. The first one represents a syncronous call, the last two are used when dealing with queues. The main method of these interfaces is perform(), that accepts a GVBuffer as input and returns the same GVBuffer as output.
Please note: When implementing a new adapter it's important not to create a new GVBuffer but to output data into the received one. The buffer contains the input/output data for all the workflow operations, thus the output has to be added into the buffer so that the Core is able to know the status and data of each operation, reporting on it and reproducing it in case of need.
