GVBuffer

From GreenVulcano Wiki
Revision as of 12:10, 9 February 2012 by Anonymous (talk) (Structure)
Jump to: navigation, search

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

WebService Wizard first window

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 and/or output operation. A GVBuffer can be also overwritten by another operation. To define a GVBuffer simply insert its identifier as input or output node's property.

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[&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="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>