GVBuffer - Revision history

C.ortenzi: /* Structure */

2012-02-14T16:06:00Z

‎Structure

D.franco: /* Description */

2012-02-14T15:42:06Z

‎Description

D.franco: /* Structure */

2012-02-14T15:15:41Z

‎Structure

D.franco: /* Example */

2012-02-14T14:13:23Z

‎Example

G.dimaio at 09:06, 14 February 2012

2012-02-14T09:06:16Z

G.dimaio at 19:11, 13 February 2012

2012-02-13T19:11:51Z

G.dimaio at 18:32, 13 February 2012

2012-02-13T18:32:05Z

G.dimaio at 18:22, 13 February 2012

2012-02-13T18:22:58Z

G.dimaio at 18:01, 13 February 2012

2012-02-13T18:01:18Z

Anonymous: /* Description */

2012-02-10T11:09:10Z

‎Description

@@ Line 16: / Line 16: @@
 All {{GVBUFFER}}s have the same shape, based on three primary components (see the image):
-*Platform fields, those fields contains all information to indentify the flow
+*Platform fields, those fields contain 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

@@ Line 1: / Line 1: @@
 ==Description==
-The {{GVBUFFER}}  data structure (it.greenvulcano.gvesb.buffer.GVBuffer) represents the container that carries information within the components of {{GVESB}}:
+The {{GVBUFFER}} data structure (it.greenvulcano.gvesb.buffer.GVBuffer) represents the container that carries information within the components of {{GVESB}}:
-Inbund Adapter <-> Core <-> Plug-in outbound
+Inbound 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 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 {{GVESB}} platform :
+The data structure contains properties specific of {{GVESB}} platform:
 *[[Service|service]]: service invoked
 *[[System|system]]: the system client identifier that invokes the service

@@ Line 15: / Line 15: @@
 [[File:GVBuffer.png|thumb|GVBuffer structure]]
-{{GVBUFFER}}s have all the same shape, based on three primary components, the following image describe this components.
+All {{GVBUFFER}}s have the same shape, based on three primary components (see the image):
 *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.

@@ Line 151: / Line 151: @@
 ====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.
+In the example below is shown a flow composed of four nodes. The first one uses as input {{GVBUFFER}} associated to the identifier 'to_process'; the result of the node processing will be into another {{GVBUFFER}} associated to the 'read_data' identifier. 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.
 <syntaxhighlight lang="XML">
@@ Line 205: / Line 205: @@
 </syntaxhighlight>
-The same example bu with OGNL.
+The same example built with OGNL.
 The comments aren't allowed in OGNL scripts, so are defined externally:
 <nowiki>#</nowiki>input is a GVBuffer instance, suppose <nowiki>#</nowiki>input.object contains a java.lang.String, then set a service specific property, and finally set a platform property

@@ Line 22: / Line 22: @@
 A single service can have more {{GVBUFFER}} instances in its [[Execution Context]], each operation (node) in a {{GVESB}} service can declare a {{GVBUFFER}} as input and/or output. A {{GVBUFFER}} in the [[Execution Context]] can be also overwritten by another operation.
-Following the {{GVBUFFER}} public fields:
+Following the {{GVBUFFER}} public fields/methods:
 <syntaxhighlight lang="java5">
 /**

@@ Line 203: / Line 203: @@
 // modify the payload
 data.setObject(obj.getBytes());
 </syntaxhighlight>

@@ Line 185: / Line 185: @@
      </GVEndNode>
 </Flow>
 </syntaxhighlight>

@@ Line 1: / Line 1: @@
 ==Description==
-The GVBuffer data structure (it.greenvulcano.gvesb.buffer.GVBuffer) represents the container that carries information within the components of {{GVESB}}:
+The {{GVBUFFER}}  data structure (it.greenvulcano.gvesb.buffer.GVBuffer) represents the container that carries information within the components of {{GVESB}}:
 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 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 {{GVESB}} platform :
-*[[Service]]: service invoked
+*[[Service|service]]: service invoked
-*[[System]]: the system client identifier that invokes the service
+*[[System|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
+*[[Id|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 contract client / server for a specific service)
+*retCode: return code of the service invocation (possibly defined by the client/server contract 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.
+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==
@@ Line 16: / Line 16: @@
 {{GVBUFFER}}s 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
+*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 all information to indentify the flow
+*Payload, This buffer section contains the service data
-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.
+A single service can have more {{GVBUFFER}} instances in its [[Execution Context]], each operation (node) in a {{GVESB}} 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 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.
+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.
 <syntaxhighlight lang="XML">
@@ Line 31: / Line 31: @@
                          id-system="CREDIT" input="to_process"
                          next-node-id="add_ext" op-type="call"
-                         operation-name="CreditCards" output="data"
+                         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="data"
+                         dump-in-out="false" id="add_ext" input="read_data"
                          next-node-id="send_email"
                          op-type="change GVBuffer" point-x="309"
@@ Line 45: / Line 45: @@
      <GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
                          dump-in-out="false" id="send_email"
-                         id-system="CREDIT" input="data"
+                         id-system="CREDIT" input="read_data"
                          next-node-id="end" op-type="call"
                          operation-name="SendEmailSVCResponse"
-                         output="data" point-x="473" point-y="137"
+                         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="data" point-x="671" point-y="137"
+                 output="read_data" point-x="671" point-y="137"
                  type="flow-node">
          <ChangeGVBuffer clear-data="true"/>