Difference between revisions of "GVBuffer"
(→Structure) |
(→Structure) |
||
Line 18: | Line 18: | ||
*Payload, This buffer section contains all information to indentify the flow | *Payload, This buffer section contains all information to indentify the flow | ||
− | To define a {{GVBUFFER}} simply insert its identifier as input or output node's property (or xml attribute). | + | A single service can have more GvBuffer, each operation (node) in a Greenvulcano service can declare a {{GVBUFFER}} as input operation and/or output. To define a {{GVBUFFER}} simply insert its identifier as input or output node's property (or xml attribute). |
− | |||
====Example==== | ====Example==== |
Revision as of 12:08, 9 February 2012
Description
The GVBuffer data structure (it.greenvulcano.gvesb.buffer.GVBuffer) represents the container that carries information within the components of GreenVulcano ESB: Inbund Adapter <-> Core <-> Plug-in outbound The business information traveling in the 'object', the GVBuffer data structure can contain any visual data type: JMS messages, SOAP Envelope, Document, strings, arrays of bytes, etc.. The data structure contains properties specific of GreenVulcano ESB platform :
- Service: service invoked
- System: the system client identifier that invokes the service
- Id: the identifier of the particular transaction (eg, to identify the response of a specific asynchronous request)
- RetCode: return code of the service invocation (possibly defined by contract client / server for a specific service)
GVBuffer The data structure also offers the ability to define and modify the properties specific service within the workflow to be used by JavaScript and / or OGNL and conditions as routing.
Structure
GVBuffers have all the same shape, based on three primary components, the following image describe this components.
- Platform fields, this buffer section contains all information to indentify the flow
- Properties, this section contains an object thats maps keys to values. This object cannot contain duplicate keys; each key can map to at most one value.
- Payload, This buffer section contains all information to indentify the flow
A single service can have more GvBuffer, each operation (node) in a Greenvulcano service can declare a GVBuffer as input operation and/or output. To define a GVBuffer simply insert its identifier as input or output node's property (or xml attribute).
Example
In the example below is shown a flow composed of Four nodes. The first one presents an incoming GVBuffer associated to the identifier 'to_process'; the result of the node will be into another GVBuffer associated to the identifier 'data'. Subsequent nodes will work on the same buffer ('data'), which will be the output parameter of the <GVEndNode>: so information in it will be delivered to the client.
<Flow first-node="extract_data" point-x="19" point-y="137">
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
dump-in-out="false" id="extract_data"
id-system="CREDIT" input="to_process"
next-node-id="add_ext" op-type="call"
operation-name="CreditCards" output="data"
point-x="149" point-y="140" type="flow-node"/>
<ChangeGVBufferNode class="it.greenvulcano.gvesb.core.flow.ChangeGVBufferNode"
dump-in-out="false" id="add_ext" input="data"
next-node-id="send_email"
op-type="change GVBuffer" point-x="309"
point-y="137" type="flow-node">
<ChangeGVBuffer clear-data="false">
<PropertyDef name="FILE_EXT"
value="decode{{ognl{{property['BIRT_REPORT_TYPE']}}::excel::xls::pdf}}"/>
</ChangeGVBuffer>
</ChangeGVBufferNode>
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
dump-in-out="false" id="send_email"
id-system="CREDIT" input="data"
next-node-id="end" op-type="call"
operation-name="SendEmailSVCResponse"
output="data" point-x="473" point-y="137"
type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
end-business-process="yes" id="end" op-type="end"
output="data" point-x="671" point-y="137"
type="flow-node">
<ChangeGVBuffer clear-data="true"/>
</GVEndNode>
</Flow>