GVBuffer

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 are inserted in the 'object' field, the GVBuffer data structure can contains any data type: JMS messages, SOAP Envelope, Document, strings, byte arrays, 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), the id is unique for the all service execution
• retCode: return code of the service invocation (possibly defined by the client/server contract for a specific service)

The data structure also offers the ability to define and modify some service specific properties within the workflow, to be used by JavaScript and/or OGNL and in evaluating routing conditions.

Structure

WebService Wizard first window

GVBuffers have all the same shape, based on three primary components, the following image describe this components.

• Platform fields, those fields 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 the service data

A single service can have more GVBuffer instances in its Execution Context, each operation (node) in a GreenVulcano^® ESB service can declare a GVBuffer as input and/or output. A GVBuffer in the Execution Context can be also overwritten by another operation.

Example

In the example below is shown a flow composed of four nodes. The first one use as input GVBuffer associated to the identifier 'to_process'; the result of the node processing will be into another GVBuffer associated to the identifier 'read_data'. Subsequent nodes will work on the same buffer ('read_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="read_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="read_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[&apos;BIRT_REPORT_TYPE&apos;]}}::excel::xls::pdf}}"/>
        </ChangeGVBuffer>
    </ChangeGVBufferNode>
    <GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
                        dump-in-out="false" id="send_email"
                        id-system="CREDIT" input="read_data"
                        next-node-id="end" op-type="call"
                        operation-name="SendEmailSVCResponse"
                        output="read_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="read_data" point-x="671" point-y="137"
                type="flow-node">
        <ChangeGVBuffer clear-data="true"/>
    </GVEndNode>
</Flow>