GreenVulcano Wiki - User contributions [en]

Statement

2016-04-05T11:19:03Z

A.capaldo: /* {{GVESB}} Configuration */

==Description==

This element defines the statement to be evaluated.

Can contains [[placeholders]] that will be replaced at runtime.

=={{GVESB}} Configuration==

The element statement can be used by:
* [[CallDescriptor]]
* [[DBOFlatSelect]]
* [[DBOInsert]]
* [[DBOInsertOrUpdate]]
* [[DBOMultiFlatSelect]]
* [[DBOSelect]]
* [[DBOThreadSelect]]
* [[DBOUpdate]]
* [[DBOUpdateOrInsert]]
* [[Excel-call#Sheet|Sheet]]

Its attributes are:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || required || Must be:
* DBOSelect : select
* DBOInsert : insert
* DBOUpdate : update
* DBOInsertOrUpdate : insert|update
* DBOUpdateOrInsert : insert|update
* DBOCallSP : callsp
* Excel Sheet : select
The attribute's admitted values are:
* select
* insert
* update
* callsp
The attribute's value cannot be null.
|-
| id || optional || Statement identifier. Default is 0. It is used as value of row/@id attribute:
* Select: identifies the statement from which have been extracted the marked rows.
* Update: identifies the statement to be used to process the input row parameters.
The attribute's value cannot be null.
|-
| keys || optional || Only useful in DBOSelect.
Specifies the index of select output on which group the results.
The corresponding values are specified as attributes of 'data' element within the 'RowSet' element.
For example, in the select: SELECT id,company_code,name FROM employees
specifying the attribute keys = "2", the result would be:
<syntaxhighlight lang="XML"><RowSet>
<data key_2="GreenVulcano">
<row><col>19</col><col>pippo</col></row>
<row><col>25</col><col>pluto</col></row>
</data>
</RowSet>
</syntaxhighlight>
Can specify multiple keys separated by commas.
The attribute's value cannot be null.
|}

Does not contain subelements.

Statement

2016-04-05T10:56:57Z

A.capaldo: /* {{GVESB}} Configuration */

==Description==

This element defines the statement to be evaluated.

Can contains [[placeholders]] that will be replaced at runtime.

=={{GVESB}} Configuration==

The element statement can be used by:
* [[CallDescriptor]]
* [[DBOFlatSelect]]
* [[DBOInsert]]
* [[DBOInsertOrUpdate]]
* [[DBOMultiFlatSelect]]
* [[DBOSelect]]
* [[DBOThreadSelect]]
* [[DBOUpdate]]
* [[DBOUpdateOrInsert]]
* [[Excel-call#Sheet|Sheet]]

Its attributes are:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || required || Must be:
* DBOSelect : select
* DBOInsert : insert
* DBOUpdate : update
* DBOInsertOrUpdate : insert|update
* DBOUpdateOrInsert : insert|update
* DBOCallSP : callsp
* Excel Sheet : select
The attribute's admitted values are:
* select
* insert
* update
* callsp
The attribute's value cannot be null.
|-
| id || optional || Statement identifier. Default is 0. It is used as value of row/@id attribute:
* Select: identifies the statement from which have been extracted the marked rows.
* Update: identifies the statement to be used to process the input row parameters.
The attribute's value cannot be null.
Incremental IDs are required if DBO uses a transformation, while same IDs (usually the default one) is required for each statement when not using a transformation.
|-
| keys || optional || Only useful in DBOSelect.
Specifies the index of select output on which group the results.
The corresponding values are specified as attributes of 'data' element within the 'RowSet' element.
For example, in the select: SELECT id,company_code,name FROM employees
specifying the attribute keys = "2", the result would be:
<syntaxhighlight lang="XML"><RowSet>
<data key_2="GreenVulcano">
<row><col>19</col><col>pippo</col></row>
<row><col>25</col><col>pluto</col></row>
</data>
</RowSet>
</syntaxhighlight>
Can specify multiple keys separated by commas.
The attribute's value cannot be null.
|}

Does not contain subelements.

GVSubFlowCallNode

2014-09-22T10:32:30Z

A.capaldo: /* {{VULCON}} / {{GVCONSOLE}} Configuration */

==Description==

Node that allows direct invocation of a {{GVESB}} core workflow sub-flow.

=={{VULCON}} / {{GVCONSOLE}} Configuration==

GVSubFlowCallNode allows to call a [[SubFlow]]: is a [[Flow]] element that extends [[FlowNode]]. Its dynamic fields can contains the [[placeholders]].

The following table shows the GVSubFlowCallNode element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| class || fixed || This attributes must assume the value '''it.greenvulcano.gvesb.core.flow.GVSubFlowCallNode'''
|-
| op-type || fixed || This attributes must assume the value '''subcall'''
|-
| dynamic || optional || If 'true' subflow attribute can contain [[Placeholders|metadata]] to be resolved at runtime.
|-
| subflow || required || Name of the sub-flow to invoke
|-
| change-log-context || optional || If 'true' log context is updated.
The default is 'false'.
|-
| on-exception-id || required || Node on which transfer control in case of exception.
Note that any item [[GVRouting]] takes precedence over the choices made by GVSubFlowCallNode.
|-
| default-id || optional || Node on which transfer control if not apply any [[GVRouting]] and are not in the case of exception.
|-
| input-ref-dp || optional || Name of [[Data_provider|Data Provider]] to use for input manipulation.
This Data Provider will receive in input a [[GVBuffer]] and must return the object to be inserted in GVBuffer.object. '''Is used BEFORE InputServices'''
|-
| output-ref-dp || optional || Name of [[Data_provider|Data Provider]] to use for output manipulation.
This Data Provider will receive in input a [[GVBuffer]] and must return the object to be inserted in GVBuffer.object. '''Is used AFTER OutputServices'''
|}

Might contain the following elements:
* [[GVRouting]]
<div class="version_ge3.4">
* [[GVOperationNode#InputServices|InputServices]]
* [[GVOperationNode#OutputServices|OutputServices]]
</div>

Field

2014-09-22T09:33:34Z

A.capaldo: /* {{GVESB}} Configuration */

==Description==

This element allows to define the key and direction of the Expression defined above.

Field element is used by [[GVDataProviderManager#DataProviders|DataProviders]].

=={{GVESB}} Configuration==

The Field Element is used by:
* [[ArrayDataProvider]]
* [[Axis2MessageContextDataProvider]]
* [[Axis2SAAJSOAPMessageDataProvider]]
* [[CollectionDataProvider]]
* [[GVBufferChangeDataProvider]]
* [[HttpMethodDataProvider]]
* [[InputStreamDataProvider]]
* [[JMSBytesMessageDataProvider]]
* [[JMSMapMessageDataProvider]]
* [[JMSObjectMessageDataProvider]]
* [[JMSStreamMessageDataProvider]]
* [[JMSTextMessageDataProvider]]
* [[MapDataProvider]]
* [[ObjectDataProvider]]
* [[StringDataProvider]]
* [[XMLEventCollectionDataProvider]].

The following table shows the Field element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| key || required || The attribute's value cannot be null.
|-
| type || fixed || This attribute must assume the value '''field'''.
|-
| direction || optional || Field direction.
* INOUT: The expression is evaluated on the object set (usually the current [[GVBuffer]], unless otherwise specified
by the attribute 'source-selector') the value returned by the expression, is added to the context with the prefix 'key_' +
@key, and set the data provider to be returned in the output.
* IN : The expression is evaluated on the object set (usually the current [[GVBuffer]], unless otherwise specified by
the attribute 'source-selector') the value returned by the expression is added to the context with the prefix 'key_' + @key.
* OUT : The expression is evaluated directly on the object that is returned by the [[Data provider]].
|}

In all cases, two variables are added to the context:
* input: object set, usually the current [[GVBuffer]], which will not be overwritten from attribute 'source-selector';
* output: the object that is returned by the [[Data provider]].

Contains a sub-element [[#Expression|Expression]].

===Expression===

The following table shows the Expression element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || required || The attribute's admitted values are:
* ognl
* xpath
* regex
<div class="version_ge3.3">
* js
</div>
|}

ExtendedInboundParamHandlerFormatter

2013-07-26T16:57:02Z

A.capaldo: /* RequestFlatParamMapping */

==Description==
This sub-element formatter is used into the decoding of client request's parameters in order to create the input for a {{GVESB}} service and to convert the service's output into a HTTP response.

DA COMPLETARE

=={{GVESB}} Configuration==
The GVAdapterHttpConfiguration Element is used by: GVAdapters.

The following table shows the '''ExtendedInboundParamHandlerFormatter''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || fixed || This attribute must keep the value '''FormatterPlugin'''.
|-
| class|| fixed || Module Id always set to '''it.greenvulcano.gvesb.adapter.http.formatters.handlers.ExtendedInboundParamHandlerFormatter'''.
|-
| ID || required || If 'true' reads the request HTTP headers and provide them with the request parameters. Default value is '''false'''.
|-
| read-request-header || optional || CharacterEncoding to be used to handle requests from external system. Default to UTF-8.
|-
| ReqCharacterEncoding || optional || CharacterEncoding to handle responses to the external system. Default to UTF-8.
|-
| RespCharacterEncoding || optional || ContentType to be declared while handling HTTP responses to the external system. Default to text/html.
|-
| RespContentType || optional || If true force the POST body to be handled as application/x-www-form-urlencoded content type. Default is false.
|-
| HandlePostBodyAsParams || optional || If != -1 force the adapter to respond with the given http code on case of error. Default is -1 (disabled).
|-
| ResponseOnError-HTTPCode || optional || CharacterEncoding to be used to handle requests from external system. Default to UTF-8.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferFieldDefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Field name: <i><xsl:value-of select="@FieldName"/></i></td>
</tr>
<tr>
<td>Field value: <i><xsl:value-of select="@FieldValue"/></i></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

Contains the sub-elements [[#GVBufferFieldDefaultValue|GVBufferFieldDefaultValue]].

Contains the sub-elements [[#GVBufferPropertyDefaultValue|GVBufferPropertyDefaultValue]].

Contains the sub-elements
[[#GVBufferField|GVBufferField]].

==GVBufferFieldDefaultValue==
The following table shows the '''GVBufferFieldDefaultValue''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || The configured default value of an GVBuffer field. Cannot be left blank.
|-
| FieldValue || required || A configured default value for a property field of an GVBuffer object.
|}

==GVBufferPropertyDefaultValue==
The name of an GVBuffer extended field.
The following table shows the '''GVBufferPropertyDefaultValue''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || This element represents a mapping target from/to a property field of an GVBuffer object.
|-
| FieldValue || required || This element represents a mapping target from/to a field of an GVBuffer object.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferPropertyDefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Extended field name: <i><xsl:value-of select="@FieldName"/></i></td>
</tr>
<tr>
<td>Extended field value: <i><xsl:value-of select="@FieldValue"/></i></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==GVBufferField==
The name of a field of an GVBuffer object.
The following table shows the '''GVBufferField''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || The configured default value of an GVBuffer extended field. Cannot be left blank.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferProperty">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Extended field name: <b><xsl:value-of select="@FieldName"/></b></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==GVBufferProperty==
The name of a field of an GVBuffer object.
The following table shows the '''GVBufferProperty''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || This element represents a plain text value to be assigned as source/target of an handler mapping.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="DefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Value length: <b><xsl:value-of select="string-length(text())"/></b> characters</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>

This element represents a mapping target from/to a list of extended field of an GVBuffer object.
Template to follow
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferPropertyList">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Excluded Extended fields names: <b><xsl:value-of select="@ExcludeFields"/></b></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==GVBufferPropertyList==
The following table shows the '''GVBufferPropertyList''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| URLEncoding|| required|| Parameters name-value separator string within list. Possible values are : '''True''', '''False'''. Default is ';'
|-
| FieldNameValueSeparator || optional || Parameters entry separator string within list. Default is '='
|-
| FieldEntrySeparator || optional || The comma separated list of extended fields names to ignore.
|-
| ExcludeFields || required || This element represents a plain text value to be assigned as source/target of an handler mapping.
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="DefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Value length: <b><xsl:value-of select="string-length(text())"/></b> characters</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestParams==
Contains the sub-elements:
* [[#RequestParam|RequestParam]]

The following table shows the '''RequestParams''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ParamNameValueSeparator|| required|| Parameters name-value separator string within list. Possible values are : '''True''', '''False'''. Default is ';'
|-
| ParamEntrySeparator|| optional || Parameters entry separator string within list. Default is '='
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestContent">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Configured handlers:</td>
<td width="20"></td>
<td><b><xsl:value-of select="count(./*[@ItemType='Handler'])"/></b></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestParam==
The following table shows the '''RequestParam''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| Name|| required|| If true the request parameter is mandatory. Possible values are : '''True''', '''False'''. Default is '''True'''.
|-
| Type|| optional || This element contains configuration informations about an inbound request XML parameter <b>Handler</b>: a Java object used to extract informations from a single parameter of an inbound http request (in the case that this parameter contains an XML string) and use them to populate one or more fields of an GVBuffer request object to be sent to GreenVulcano.

This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestXMLParamHandler">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Output type: <b><xsl:value-of select="@OutputType"/></b></td>
</tr>
<tr>
<td>Maps parameter contents to:</td>
<td width="20"></td>
</tr>
<tr>
<td>
<ul>
<xsl:for-each select="RequestXMLParamMapping">
<xsl:if test="GVBufferField">
<li>field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="GVBufferProperty">
<li>extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="OpType">
<li><i>OperationType</i> variable (GreenVulcano communication paradigm)</li>
</xsl:if>
</xsl:for-each>
</ul>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestXMLParamHandler==
Contains the sub-elements:
* [[#RequestXMLParamMapping|RequestXMLParamMapping]]

The following table shows the '''RequestXMLParamHandler''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed|| Inbound request parameter/content format.
|-
| Class || optional || The output type of this inbound request parameter handler (GVBuffer object or communication paradigm string).
|-
| OutputType || fixed|| This element contains a mapping between a value extracted by an element or attribute (within XML content of an inbound request parameter) matching a given XPath, and a field of a request GVBuffer object. If mapping target is indicated with the "OpType" keyword, the value is a string indicating the requested communication paradigm (RequestReply, Request, SendReply, GetRequest, GetReply). Possible values are '''GVBuffer''', '''OpType'''.

This is the template used:
<syntaxhighlight lang="XML">

<xsl:template match="RequestXMLParamMapping">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler mapping.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Mapping source: <b><xsl:value-of select="@XPath"/></b></td>
</tr>
<tr>
<td>Mapping target:
<xsl:if test="GVBufferField">
field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer
</xsl:if>
<xsl:if test="GVBufferProperty">
extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer
</xsl:if>
<xsl:if test="OpType">
<i>OperationType</i> variable (GreenVulcano communication paradigm)
</xsl:if>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestXMLParamMapping==
Element type (used for XPath navigation).
Contains the sub-elements:
* [[#GVBufferField|GVBufferField]]
* [[#GVBufferProperty|GVBufferProperty]]
* [[#GVBufferPropertyList|GVBufferPropertyList]]
* [[#OpType|OpType]]

The following table shows the '''RequestXMLParamMapping''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed|| XPath of an element or attribute (within XML content of an inbound request parameter).
|-
| XPath || required || This element contains configuration informations about an inbound request Flat parameter <b>Handler</b>: a Java object used to extract informations from a single parameter of an inbound http request (in the case that this parameter contains a Flat string) and use them to populate one or more fields of an GVBuffer request object to be sent to GreenVulcano.
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestFlatParamHandler">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Output type: <b><xsl:value-of select="@OutputType"/></b></td>
</tr>
<tr>
<td>Maps parameter contents to:</td>
<td width="20"></td>
</tr>
<tr>
<td>
<ul>
<xsl:for-each select="RequestFlatParamMapping">
<xsl:if test="GVBufferField">
<li>field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="GVBufferProperty">
<li>extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="OpType">
<li><i>OperationType</i> variable (GreenVulcano communication paradigm)</li>
</xsl:if>
</xsl:for-each>
</ul>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestFlatParamHandler==
Element type (used for XPath navigation).
Contains the sub-elements:
* [[#RequestFlatParamMapping|RequestFlatParamMapping]]

The following table shows the '''RequestFlatParamHandler''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed|| Inbound request parameter/content format.
|-
| Class || fixed|| The output type of this inbound request parameter handler (GVBuffer object or communication paradigm string).
|-
| OutputType || required|| The separator character between fields within the flat string value of this inbound request parameter.
Possible values are '''GVBuffer''', OpType'''.
|-
| SeparatorChar || optional || This element contains a mapping between a value extracted from a flat string (the content of an inbound request parameter), and a field of a request GVBuffer object. If mapping target is indicated with the "OpType" keyword, the value is a string indicating the requested communication paradigm (RequestReply, Request, SendReply, GetRequest, GetReply).
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestFlatParamMapping">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler mapping.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Mapping source offset: <b><xsl:value-of select="@Offset"/></b></td>
</tr>
<xsl:if test="@Length">
<tr>
<td>Mapping source Length: <b><xsl:value-of select="@Length"/></b></td>
</tr>
</xsl:if>
<tr>
<td>Mapping target:
<xsl:if test="GVBufferField">
field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer
</xsl:if>
<xsl:if test="GVBufferProperty">
extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer
</xsl:if>
<xsl:if test="OpType">
<i>OperationType</i> variable (GreenVulcano communication paradigm)
</xsl:if>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestFlatParamMapping==
Element type (used for XPath navigation).
Contains the sub-elements:
* [[#GVBufferField|GVBufferField]]
* [[#GVBufferProperty|GVBufferProperty]]
* [[#OpType|OpType]]

The following table shows the '''RequestFlatParamMapping''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed || The offset of a field within the flat string value of this inbound request parameter.
|-
| Offset || required || The length of a field within the flat string value of this inbound request parameter. Not needed if a field separator char has already been specified.
|-
| Length || optional || The place where unneeded filling WhiteSpaces can be present. These spaces will be trimmed by the Adapter.
Possible values are:
'''left''', to trim leading white spaces
'''right''', to trim trailing white spaces
'''both''', to trim both leading and trailing spaces
If it is specified a value different from these above, no trimming will be performed
|-
| Trim || optional || This element contains configuration informations about an inbound request Flat parameter <b>Handler</b>: a Java object used to extract informations from a single parameter of an inbound http request (in the case that this parameter contains a plain text string) and use them to populate one or more fields of an GVBuffer request object to be sent to GreenVulcano.
Possible values are:
'''left''', '''right''','''both'''.
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestStringParamHandler">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Output type: <b><xsl:value-of select="@OutputType"/></b></td>
</tr>
<tr>
<td>Maps parameter contents to:</td>
<td width="20"></td>
</tr>
<tr>
<td>
<ul>
<xsl:for-each select="RequestStringParamMapping">
<xsl:if test="GVBufferField">
<li>field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="GVBufferProperty">
<li>extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="OpType">
<li><i>OperationType</i> variable (GreenVulcano communication paradigm)</li>
</xsl:if>
</xsl:for-each>
</ul>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestStringParamHandler==
Element type (used for XPath navigation).
Contains the sub-elements:
* [[#RequestStringParamMapping|RequestStringParamMapping]]

The following table shows the '''RequestStringParamHandler''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed || Inbound request parameter/content format.
|-
| Class || fixed || The output type of this inbound request parameter handler (GVBuffer object or communication paradigm string).
|-
| OutputType || required || This element contains a mapping between a value extracted from a plain text string (the value of an inbound request parameter), and a field of a request GVBuffer object. If mapping target is indicated with the "OpType" keyword, the value is a string indicating the requested communication paradigm (RequestReply, Request, SendReply, GetRequest, GetReply).

Possible values are:
'''GVBuffer''', '''OpType'''.

This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestStringParamMapping">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler mapping.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Mapping target:
<xsl:if test="GVBufferField">
field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer
</xsl:if>
<xsl:if test="GVBufferProperty">
extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer
</xsl:if>
<xsl:if test="OpType">
<i>OperationType</i> variable (GreenVulcano communication paradigm)
</xsl:if>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

ExtendedInboundParamHandlerFormatter

2013-07-26T16:51:31Z

A.capaldo: /* RequestFlatParamHandler */

ExtendedInboundParamHandlerFormatter

2013-07-26T16:32:41Z

A.capaldo: /* RequestFlatParamHandler */

ExtendedInboundParamHandlerFormatter

2013-07-26T16:31:44Z

A.capaldo: /* RequestXMLParamMapping */

==Description==
This sub-element formatter is used into the decoding of client request's parameters in order to create the input for a {{GVESB}} service and to convert the service's output into a HTTP response.

DA COMPLETARE

=={{GVESB}} Configuration==
The GVAdapterHttpConfiguration Element is used by: GVAdapters.

The following table shows the '''ExtendedInboundParamHandlerFormatter''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || fixed || This attribute must keep the value '''FormatterPlugin'''.
|-
| class|| fixed || Module Id always set to '''it.greenvulcano.gvesb.adapter.http.formatters.handlers.ExtendedInboundParamHandlerFormatter'''.
|-
| ID || required || If 'true' reads the request HTTP headers and provide them with the request parameters. Default value is '''false'''.
|-
| read-request-header || optional || CharacterEncoding to be used to handle requests from external system. Default to UTF-8.
|-
| ReqCharacterEncoding || optional || CharacterEncoding to handle responses to the external system. Default to UTF-8.
|-
| RespCharacterEncoding || optional || ContentType to be declared while handling HTTP responses to the external system. Default to text/html.
|-
| RespContentType || optional || If true force the POST body to be handled as application/x-www-form-urlencoded content type. Default is false.
|-
| HandlePostBodyAsParams || optional || If != -1 force the adapter to respond with the given http code on case of error. Default is -1 (disabled).
|-
| ResponseOnError-HTTPCode || optional || CharacterEncoding to be used to handle requests from external system. Default to UTF-8.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferFieldDefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Field name: <i><xsl:value-of select="@FieldName"/></i></td>
</tr>
<tr>
<td>Field value: <i><xsl:value-of select="@FieldValue"/></i></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

Contains the sub-elements [[#GVBufferFieldDefaultValue|GVBufferFieldDefaultValue]].

Contains the sub-elements [[#GVBufferPropertyDefaultValue|GVBufferPropertyDefaultValue]].

Contains the sub-elements
[[#GVBufferField|GVBufferField]].

==GVBufferFieldDefaultValue==
The following table shows the '''GVBufferFieldDefaultValue''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || The configured default value of an GVBuffer field. Cannot be left blank.
|-
| FieldValue || required || A configured default value for a property field of an GVBuffer object.
|}

==GVBufferPropertyDefaultValue==
The name of an GVBuffer extended field.
The following table shows the '''GVBufferPropertyDefaultValue''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || This element represents a mapping target from/to a property field of an GVBuffer object.
|-
| FieldValue || required || This element represents a mapping target from/to a field of an GVBuffer object.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferPropertyDefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Extended field name: <i><xsl:value-of select="@FieldName"/></i></td>
</tr>
<tr>
<td>Extended field value: <i><xsl:value-of select="@FieldValue"/></i></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==GVBufferField==
The name of a field of an GVBuffer object.
The following table shows the '''GVBufferField''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || The configured default value of an GVBuffer extended field. Cannot be left blank.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferProperty">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Extended field name: <b><xsl:value-of select="@FieldName"/></b></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==GVBufferProperty==
The name of a field of an GVBuffer object.
The following table shows the '''GVBufferProperty''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| FieldName || required || This element represents a plain text value to be assigned as source/target of an handler mapping.
Template to follow:
<syntaxhighlight lang="XML">
<xsl:template match="DefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Value length: <b><xsl:value-of select="string-length(text())"/></b> characters</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>

This element represents a mapping target from/to a list of extended field of an GVBuffer object.
Template to follow
<syntaxhighlight lang="XML">
<xsl:template match="GVBufferPropertyList">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Excluded Extended fields names: <b><xsl:value-of select="@ExcludeFields"/></b></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==GVBufferPropertyList==
The following table shows the '''GVBufferPropertyList''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| URLEncoding|| required|| Parameters name-value separator string within list. Possible values are : '''True''', '''False'''. Default is ';'
|-
| FieldNameValueSeparator || optional || Parameters entry separator string within list. Default is '='
|-
| FieldEntrySeparator || optional || The comma separated list of extended fields names to ignore.
|-
| ExcludeFields || required || This element represents a plain text value to be assigned as source/target of an handler mapping.
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="DefaultValue">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Value length: <b><xsl:value-of select="string-length(text())"/></b> characters</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestParams==
Contains the sub-elements:
* [[#RequestParam|RequestParam]]

The following table shows the '''RequestParams''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ParamNameValueSeparator|| required|| Parameters name-value separator string within list. Possible values are : '''True''', '''False'''. Default is ';'
|-
| ParamEntrySeparator|| optional || Parameters entry separator string within list. Default is '='
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestContent">
<table cellpadding="0" cellspacing="0">
<tr>
<td>Configured handlers:</td>
<td width="20"></td>
<td><b><xsl:value-of select="count(./*[@ItemType='Handler'])"/></b></td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestParam==
The following table shows the '''RequestParam''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| Name|| required|| If true the request parameter is mandatory. Possible values are : '''True''', '''False'''. Default is '''True'''.
|-
| Type|| optional || This element contains configuration informations about an inbound request XML parameter <b>Handler</b>: a Java object used to extract informations from a single parameter of an inbound http request (in the case that this parameter contains an XML string) and use them to populate one or more fields of an GVBuffer request object to be sent to GreenVulcano.

This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestXMLParamHandler">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Output type: <b><xsl:value-of select="@OutputType"/></b></td>
</tr>
<tr>
<td>Maps parameter contents to:</td>
<td width="20"></td>
</tr>
<tr>
<td>
<ul>
<xsl:for-each select="RequestXMLParamMapping">
<xsl:if test="GVBufferField">
<li>field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="GVBufferProperty">
<li>extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="OpType">
<li><i>OperationType</i> variable (GreenVulcano communication paradigm)</li>
</xsl:if>
</xsl:for-each>
</ul>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestXMLParamHandler==
Contains the sub-elements:
* [[#RequestXMLParamMapping|RequestXMLParamMapping]]

The following table shows the '''RequestXMLParamHandler''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed|| Inbound request parameter/content format.
|-
| Class || optional || The output type of this inbound request parameter handler (GVBuffer object or communication paradigm string).
|-
| OutputType || fixed|| This element contains a mapping between a value extracted by an element or attribute (within XML content of an inbound request parameter) matching a given XPath, and a field of a request GVBuffer object. If mapping target is indicated with the "OpType" keyword, the value is a string indicating the requested communication paradigm (RequestReply, Request, SendReply, GetRequest, GetReply). Possible values are '''GVBuffer''', '''OpType'''.

This is the template used:
<syntaxhighlight lang="XML">

<xsl:template match="RequestXMLParamMapping">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler mapping.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Mapping source: <b><xsl:value-of select="@XPath"/></b></td>
</tr>
<tr>
<td>Mapping target:
<xsl:if test="GVBufferField">
field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer
</xsl:if>
<xsl:if test="GVBufferProperty">
extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer
</xsl:if>
<xsl:if test="OpType">
<i>OperationType</i> variable (GreenVulcano communication paradigm)
</xsl:if>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestXMLParamMapping==
Element type (used for XPath navigation).
Contains the sub-elements:
* [[#GVBufferField|GVBufferField]]
* [[#GVBufferProperty|GVBufferProperty]]
* [[#GVBufferPropertyList|GVBufferPropertyList]]
* [[#OpType|OpType]]

The following table shows the '''RequestXMLParamMapping''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed|| XPath of an element or attribute (within XML content of an inbound request parameter).
|-
| XPath || required || This element contains configuration informations about an inbound request Flat parameter <b>Handler</b>: a Java object used to extract informations from a single parameter of an inbound http request (in the case that this parameter contains a Flat string) and use them to populate one or more fields of an GVBuffer request object to be sent to GreenVulcano.
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestFlatParamHandler">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Output type: <b><xsl:value-of select="@OutputType"/></b></td>
</tr>
<tr>
<td>Maps parameter contents to:</td>
<td width="20"></td>
</tr>
<tr>
<td>
<ul>
<xsl:for-each select="RequestFlatParamMapping">
<xsl:if test="GVBufferField">
<li>field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="GVBufferProperty">
<li>extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer</li>
</xsl:if>
<xsl:if test="OpType">
<li><i>OperationType</i> variable (GreenVulcano communication paradigm)</li>
</xsl:if>
</xsl:for-each>
</ul>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

==RequestFlatParamHandler==
Element type (used for XPath navigation).
Contains the sub-elements:
* [[#RequestFlatParamMapping|RequestFlatParamMapping]]

The following table shows the '''RequestFlatParamHandler''' attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| ItemType || fixed|| Inbound request parameter/content format.
|-
| Class || fixed|| The output type of this inbound request parameter handler (GVBuffer object or communication paradigm string).
|-
| OutputType || required|| The separator character between fields within the flat string value of this inbound request parameter.
Possible values are '''GVBuffer''', OpType'''.
| SeparatorChar || optional || This element contains a mapping between a value extracted from a flat string (the content of an inbound request parameter), and a field of a request GVBuffer object. If mapping target is indicated with the "OpType" keyword, the value is a string indicating the requested communication paradigm (RequestReply, Request, SendReply, GetRequest, GetReply).
This is the template used:
<syntaxhighlight lang="XML">
<xsl:template match="RequestFlatParamMapping">
<table cellpadding="0" cellspacing="0">
<xsl:choose>
<xsl:when test="../../@Name">
<tr>
<td>Inbound request parameter handled:</td>
<td width="20"></td>
<td><b><xsl:value-of select="../../@Name"/></b></td>
</tr>
</xsl:when>
<xsl:otherwise>
<tr>
<td>Inbound request content handler mapping.</td>
</tr>
</xsl:otherwise>
</xsl:choose>
<tr>
<td>Mapping source offset: <b><xsl:value-of select="@Offset"/></b></td>
</tr>
<xsl:if test="@Length">
<tr>
<td>Mapping source Length: <b><xsl:value-of select="@Length"/></b></td>
</tr>
</xsl:if>
<tr>
<td>Mapping target:
<xsl:if test="GVBufferField">
field <b><xsl:value-of select="substring-after(GVBufferField/@FieldName, 'GVBuffer.')"/></b> of GVBuffer
</xsl:if>
<xsl:if test="GVBufferProperty">
extended field <b><xsl:value-of select="GVBufferProperty/@FieldName"/></b> of GVBuffer
</xsl:if>
<xsl:if test="OpType">
<i>OperationType</i> variable (GreenVulcano communication paradigm)
</xsl:if>
</td>
</tr>
</table>
</xsl:template>
</syntaxhighlight>
|}

ExtendedInboundParamHandlerFormatter

2013-07-26T16:26:09Z

A.capaldo: /* RequestXMLParamHandler */

ExtendedInboundParamHandlerFormatter

2013-07-26T16:16:02Z

A.capaldo: /* RequestParam */

ExtendedInboundParamHandlerFormatter

2013-07-26T16:15:25Z

A.capaldo: /* RequestParams */

ExtendedInboundParamHandlerFormatter

2013-07-26T16:02:58Z

A.capaldo: /* GVBufferPropertyList */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:48:45Z

A.capaldo: /* GVBufferProperty */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:38:45Z

A.capaldo: /* GVBufferProperty */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:36:08Z

A.capaldo: /* GVBufferField */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:35:26Z

A.capaldo: /* GVBufferProperty */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:34:15Z

A.capaldo: /* GVBufferProperty */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:32:27Z

A.capaldo: /* GVBufferProperty */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:31:09Z

A.capaldo: /* GVBufferPropertyDefaultValue */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:28:59Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:28:06Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:26:38Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:24:23Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:23:22Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:22:21Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:21:17Z

A.capaldo: /* GVBufferPropertyDefaultValue */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:15:47Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:14:02Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:13:36Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:07:09Z

A.capaldo: /* GVBufferFieldDefaultValue */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:05:11Z

A.capaldo: /* GVBufferFieldDefaultValue */

ExtendedInboundParamHandlerFormatter

2013-07-26T15:04:36Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T14:55:10Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T14:53:08Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T14:42:33Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T14:31:51Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T14:30:17Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T13:35:52Z

A.capaldo: /* {{GVESB}} Configuration */

ExtendedInboundParamHandlerFormatter

2013-07-26T13:32:06Z

A.capaldo: /* Description */

ExtendedInboundParamHandlerFormatter

2013-07-26T13:29:02Z

A.capaldo: Created page with "==Description== This sub-element formatter is used into the decoding of client request's parameters in order to create the input for a {{GVESB}} service and to convert the servic..."

GVExample TOUPPER A

2012-10-09T14:48:28Z

A.capaldo: /* Defining Workflow Operations */

==Description==

This simple example shows how to configure an asynchronous service with a [[GVForwards|JMS Forward]] .
The Service TOUPPER_A is composed of three workflows that define the Client/ESB/Server interaction:
# the Client invokes the ''Request'' workflow to enqueue the input data into a request queue
# the [[GVForwards|JMS Forward]] (a {{GVESB}} component), listening on the request queue, extracts the JMS message and invokes the ''FWD_TOUPPER_A'' workflow that converts the payload to uppercase (simulate a Server invocation) then enqueues the new payload into a response queue
# the Client invokes the ''getReply'' workflow to dequeue the output data from a response queue

==How To==

The preferred mode for creating a Service (at least its skeleton) is through the Service Wizard. Before using it you must first configure the JMS Queue and the VCL plugins to interact with the JMS queue and execute the uppercase conversion. So let's define a new Group, System and Channel, if you do not want to use those already present, and then start the Wizard.

===Configuring JMS queues in JBoss===

The JMS queues are configured in JBoss by an XML file, ''gvesb-mq-destinations-service.xml'' present in <nowiki>$GV_HOME</nowiki>/application/deploy.

A queue has:
* A name that serves to identify it to JBoss.
* A JNDI Name used by a client to connect to the queue.
* MaxDeliveryAttempts (optional), to indicate how many times a message is put back into the queue for processing if the application does not confirm its reading.
* RedeliveryDelay (optional), to indicate the delay (in ms) after a message will be put back into the queue if the application does not confirm its reading.

The JndiName can be checked using the JBoss's jmx-console to find the MBean "service=JNDIView".

In this example we use 2 queues:
* ''TOUPPER_A_Request_Queue''
* ''TOUPPER_A_Response_Queue''

To configure both queues go to the configuration file and insert the following MBean definitions:
<syntaxhighlight lang="XML">
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=TOUPPER_A_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/TOUPPER_A_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=TOUPPER_A_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/TOUPPER_A_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
</syntaxhighlight>

===Defining Group, System and Channel===

From the core view:
# Right click the element Groups -> Insert after (or Insert before) -> Group. A new element Group will be created.
# Click on the Group new element and set the attribute ''id-group'' from the Properties View. We named it DEFAULT_GRP
# Expand the GVSystems item.
# Right clicking on Systems, insert-after -> System. A new element System will be created.
# Set the [[System]] parameters in the [[VulCon_perspective|Properties panel]]. We named it GVESB_TEST
# You can insert a new [[Channel]] right clicking the new [[System]] element -> Insert after (or Insert before) -> Channel*. A new Channel element will be created
# Click on this new Channel element and set the property ''id_channel''. We named it TEST_CHANNEL_A

===Defining Workflow Operations===

Once you have created the [[Channel]], insert into the operations you need for the workflow. In this case:

{|class="gvtable"
! Plugin !! Value
|-
| [[jms-enqueue]] || connection-factory="java:/XAConnectionFactory"<br/>destination-name="gvesb/jms/queue/TOUPPER_A_Request_Queue"<br/>name="JMSEnqueueTo::TOUPPER_A_Req"<br/> ref-dp="WriteString_JMSBytesMessageDataProvider"<br/>XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"<br/>(You can find XAHelper section by adding it on the queue)
|-
| [[jms-enqueue]] || connection-factory="java:/XAConnectionFactory"<br/>delivery-mode="persistent"<br/>destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue"<br/>name="JMSEnqueueTo::TOUPPER_A_Resp"<br/> ref-dp="WriteString_JMSBytesMessageDataProvider"<br/>XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"
|-
| [[jms-dequeue]] || connection-factory="java:/XAConnectionFactory"<br/>delivery-mode="persistent"<br/>destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue"<br/>name="JMSDequeueTo::TOUPPER_A_Resp"<br/> ref-dp="ReadString_JMSBytesMessageDataProvider"<br/> receive-type="timeout"<br/>XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"
|-
| [[test-service-call]] || name="toupper_call" service="toupper"
|}

The ''WriteString_JMSBytesMessageDataProvider'' creates a JMS BytesMessage and write in its body the expected input java.lang.String converted to byte[].<br/>The ''ReadString_JMSBytesMessageDataProvider'' extract the input JMS BytesMessage body as byte[] then convert it into a java.lang.String.<br/>Check that [[Data provider|Data Providers]] ''WriteString_JMSBytesMessageDataProvider'' and ''ReadString_JMSBytesMessageDataProvider'' will be present in the element DataProviders (JMSBytesMessageDataProvider and StringDataProvider respectively), visualized from the {{VULCON}} Adapter view. If don't, you can add it setting their attributes as seen in the following table:
{|class="gvtable"
! Data Provider !! Value
|-
| [[Data provider|JMSBytesMessageDataProvider]] || name="WriteString_JMSBytesMessageDataProvider"<br/>Field:
: direction="OUT" key="output" type="field">
: Expression: type="ognl"
:: writeBytes(#input.object.getBytes('UTF-8'))
|-
| [[Data provider|StringDataProvider]] || name="ReadString_JMSBytesMessageDataProvider"<br/>Field:
: direction="INOUT" key="buffer" type="field"
: Expression: type="ognl"
:: #bArr = new byte[object.getBodyLength()], object.reset(), object.readBytes(#bArr), new java.lang.String(#bArr, 'UTF-8')
|}

[[File:NewServiceWizard.jpg|thumb|New {{GVESB}} Service Wizard]]Now we are able to use the Wizard.
# From the Core View of {{VULCON}}. Right click the element Services -> Wizard New Service
# A new windows will be open where you can set the name of the Service you want to create, in this case we named TOUPPER_A, and your Group, we used DEFAULT_GRP. You can also select the paradigm, for this example will be [[Paradigms_of_communication#asynchronous-synchronous|asynchronous-synchronous]]. Click next.
# Set System as GVESB_TEST and Channel as TEST_CHANNEL_A. Then chose as Request Operation ''JMSEnqueueTo::TOUPPER_A_Req'', and the response Operation ''toupper_call''. Then finish.

[[File:GVExamplesTOUPPER_AEditor.jpg |thumb |TOUPPER_A flow]]As you can see from the core view, inside the Services element, a new Service named TOUPPER_A has been created.<br/>This service contains three Operations (Workflows)
We setted the first one as a Request (to enqueue), and the second as a GetReply (to dequeue).
Nodes will be setted as seen in the following table:
{|class="gvtable"
! Node !! Request !! GetReply
|-
| GVOperationNode || output: output_JMSEnqueueTo::TOUPPER_A_Req<br/>id="request"<br/>id-system="GVESB_TEST"<br/>input="input_JMSEnqueueTo::TOUPPER_A_Req"<br/>next-node-id="check_status" op-type="enqueue"<br/>operation-name="JMSEnqueueTo::TOUPPER_A_Req" || output: "output_JMSDequeueTo::TOUPPER_A_Resp"<br/>id="request"<br/>id-system="GVESB_TEST"<br/>input="input_JMSDequeueTo::TOUPPER_A_Resp"<br/>next-node-id="check_status" op-type="dequeue"<br/>operation-name="JMSDequeueTo::TOUPPER_A_Resp"<br/>DequeueFilter:
: IDFilter
:: enabled="yes" use-input="yes"
|-
| GVNodeCheck || default-id="return_status"<br/>id="check_status"<br/>input="output_JMSEnqueueTo::TOUPPER_A_Req"<br/>on-exception-id="return_error"<br/>op-type="check" || default-id="return_status"<br/>id="check_status"<br/>input="output_JMSDequeueTo::TOUPPER_A_Resp"<br/>on-exception-id="return_error"<br/>op-type="check"
|-
| GVEndNode || id="return_status"<br/>op-type="end"<br/>output="output_JMSEnqueueTo::TOUPPER_A_Req" || id="return_status"<br/>op-type="end"<br/>output="output_JMSDequeueTo::TOUPPER_A_Resp"
|-
| GVEndNode || id="return_error"<br/>output="output_JMSEnqueueTo::TOUPPER_A_Req" || id="return_error"<br/>output="output_JMSDequeueTo::TOUPPER_A_Resp"
|}

Operation FWD_TOUPPER_A will be configured as follow:
Attributes: name="Forward" operation-activation="on" out-check-type="none"
{|class="gvtable"
! Nodes/Subelements !! Attributes
|-
| GVOperationNode || id-system="GVESB"<br/> input="input"<br/> next-node-id="enqueue_response" op-type="call"<br/> operation-name="toupper_call" output="output"
|-
| GVOperationNode || id="enqueue_response" id-system="GVESB"<br/> input="output" next-node-id="end"<br/> op-type="enqueue"<br/> operation-name="JMSEnqueueTo::TOUPPER_A_Resp"<br/> output="output"
|-
| GVEndNode || end-business-process="no" id="end" op-type="end"<br/> output="output" <br/> ChangeGVBuffer: clear-data="true"
|}

The GVCore.xml configuration file will be changed as follow:
* Into ''GVForwards'' element will be added the tag
<syntaxhighlight lang="XML">
<ForwardConfiguration dump-message="true" enabled="true"
forwardName="FWD_TOUPPER_A"
ref-dp="ReadString_JMSBytesMessageDataProvider">
<ForwardDeployment connection-factory="java:/XAConnectionFactory"
destination="gvesb/jms/queue/TOUPPER_A_Request_Queue"
destination-type="queue" reconnect-interval-sec="10"
transacted="true" transaction-timeout-sec="30">
<XAHelper auto-enlist="false" transaction-status="TMSUCCESS"/>
</ForwardDeployment>
</ForwardConfiguration>
</syntaxhighlight>
* Into ''Services'' element will be added the tag
<syntaxhighlight lang="XML">
<Service group-name="DEFAULT_GRP" id-service="TOUPPER_A"
service-activation="on" statistics="off">
<Operation name="Request" operation-activation="on"
out-check-type="sys-svc-tid" type="operation">
<Description>VulCon generated Operation</Description>
<Participant id-channel="TEST_CHANNEL_A" id-system="GVESB_TEST"/>
<Flow first-node="request" point-x="50" point-y="150">
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
id="request" id-system="GVESB_TEST"
input="input_JMSEnqueueTo::TOUPPER_A_Req"
next-node-id="check_status" op-type="enqueue"
operation-name="JMSEnqueueTo::TOUPPER_A_Req"
output="output_JMSEnqueueTo::TOUPPER_A_Req"
point-x="200" point-y="150" type="flow-node"/>
<GVNodeCheck class="it.greenvulcano.gvesb.core.flow.GVNodeCheck"
default-id="return_status" id="check_status"
input="output_JMSEnqueueTo::TOUPPER_A_Req"
on-exception-id="return_error" op-type="check"
point-x="350" point-y="150" type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
id="return_status" op-type="end"
output="output_JMSEnqueueTo::TOUPPER_A_Req"
point-x="700" point-y="150" type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
id="return_error" op-type="end"
output="output_JMSEnqueueTo::TOUPPER_A_Req"
point-x="350" point-y="300" type="flow-node"/>
</Flow>
</Operation>
<Operation name="GetReply" operation-activation="on"
out-check-type="sys-svc-tid" type="operation">
<Description>VulCon generated Operation</Description>
<Participant id-channel="TEST_CHANNEL_A" id-system="GVESB_TEST"/>
<Flow first-node="request" point-x="50" point-y="150">
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
id="request" id-system="GVESB_TEST"
input="input_JMSDequeueTo::TOUPPER_A_Resp"
next-node-id="check_status" op-type="dequeue"
operation-name="JMSDequeueTo::TOUPPER_A_Resp"
output="output_JMSDequeueTo::TOUPPER_A_Resp"
point-x="200" point-y="150" type="flow-node">
<DequeueFilter>
<IDFilter enabled="yes" name="IDFilter" type="filter"
use-input="yes"/>
</DequeueFilter>
</GVOperationNode>
<GVNodeCheck class="it.greenvulcano.gvesb.core.flow.GVNodeCheck"
default-id="return_status" id="check_status"
input="output_JMSDequeueTo::TOUPPER_A_Resp"
on-exception-id="return_error" op-type="check"
point-x="350" point-y="150" type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
id="return_status" op-type="end" output="output_null"
point-x="700" point-y="150" type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
id="return_error" op-type="end"
output="output_JMSDequeueTo::TOUPPER_A_Resp"
point-x="350" point-y="300" type="flow-node"/>
</Flow>
</Operation>
<Operation forward-name="FWD_TOUPPER_A" name="Forward"
operation-activation="on" out-check-type="none"
type="operation">
<Participant id-channel="TEST_CHANNEL_A" id-system="GVESB"/>
<Flow first-node="call_server" point-x="20" point-y="150">
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
id="call_server" id-system="GVESB" input="input"
next-node-id="enqueue_response" op-type="call"
operation-name="toupper_call" output="output"
point-x="147" point-y="148" type="flow-node"/>
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
id="enqueue_response" id-system="GVESB"
input="output" next-node-id="end"
op-type="enqueue"
operation-name="JMSEnqueueTo::TOUPPER_A_Resp"
output="output" point-x="319" point-y="152"
type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
end-business-process="no" id="end" op-type="end"
output="output" point-x="532" point-y="149"
type="flow-node">
<ChangeGVBuffer clear-data="true"/>
</GVEndNode>
</Flow>
</Operation>
</Service>
</syntaxhighlight>
* Into ''System'' element will be added the tag
<syntaxhighlight lang="XML">
<Channel id-channel="TEST_CHANNEL_A">
<jms-enqueue acknowledge-type="auto-acknowledge"
class="it.greenvulcano.gvesb.virtual.j2ee.JMSEnqueueOperation"
connection-factory="java:/XAConnectionFactory"
delivery-mode="persistent"
destination-name="gvesb/jms/queue/TOUPPER_A_Request_Queue"
destination-type="queue"
name="JMSEnqueueTo::TOUPPER_A_Req" priority="4"
ref-dp="WriteString_JMSBytesMessageDataProvider"
transacted="false" type="enqueue">
<XAHelper auto-enlist="false" transaction-status="TMSUCCESS"/>
</jms-enqueue>
<jms-enqueue acknowledge-type="auto-acknowledge"
class="it.greenvulcano.gvesb.virtual.j2ee.JMSEnqueueOperation"
connection-factory="java:/XAConnectionFactory"
delivery-mode="persistent"
destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue"
destination-type="queue"
name="JMSEnqueueTo::TOUPPER_A_Resp" priority="4"
transacted="false" type="enqueue">
<XAHelper auto-enlist="false" transaction-status="TMSUCCESS"/>
</jms-enqueue>
<jms-dequeue acknowledge-type="auto-acknowledge"
class="it.greenvulcano.gvesb.virtual.j2ee.JMSDequeueOperation"
connection-factory="java:/XAConnectionFactory"
destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue"
destination-type="queue"
name="JMSDequeueTo::TOUPPER_A_Resp"
receive-timeout-overridable="false"
receive-type="timeout" transacted="false" type="dequeue">
<XAHelper auto-enlist="false" transaction-status="TMSUCCESS"/>
</jms-dequeue>
<test-service-call class="it.greenvulcano.gvesb.virtual.internal.TestServiceCall"
name="toupper_call" service="toupper" type="call"/>
</Channel>
</syntaxhighlight>

Now you are able to test your first {{VULCON}} service from the {{L_GVCONSOLE}}. But first you need to export the configuration.

[[File:GVExamplesTOUPPER5.jpg|thumb|Exporting configuration]]Once the flow is correctly configured, the user can export the configuration and pass it to the {{GVESB}} import tool, in order to add into the {{GVESB}} the service just created.

# The Export function is available in the view "Project". Expand the project
# Before you proceed press F5 to refresh the file list.
# Right click the ''conf'' folder. It will open a drop-down list.
# Export your project as a compressed file.

===Testing with {{GVCONSOLE}}===

It is finally the time to test your project. To do that execute the following steps:

[[File:GVCONSOLEDeploy.jpg|thumb|Deploy new Service]]Suppose you have saved the {{VULCON}} project as <nowiki>"${{gv.app.home}}/TEST/REPG1.zip"</nowiki>. To deploy the new Service follow this steps:
# [[Starting|Start {{GVESB}}]]
# [[GV_Console#Access|Access to the {{GVCONSOLE}}]].
# In the Deploy New Service section click Browse and select the file where you saved the {{VULCON}} configuration.
# Click Submit.

The section [[Deploy_Service|Deploy Services]] will be open. In this section you can select the services you want to deploy.
# Clicking on service TOUPPER_A a new view will be showed containing the files GVCore.xml present in local and on server side.
# Click Deploy. Now you can save the document and write some notes about it.
# Save the Document. By saving you will return to the [[Deploy Service]] section.

[[File:GVConsoleUtilityReload1.jpg|thumb|{{GVCONSOLE}} Utility section]]Now pass to the {{GVCONSOLE}} section [[Utility]].
# Click on [[Reload_Configuration|Reload configuration]]
# Select GVCore.xml and GVAdapter.xml, then Reload. A new windows will be open to confirm the operation
# Click OK.

[[File:GVConsoleTesting.jpg|thumb|{{GVCONSOLE}} Testing section]]Go to the {{GVCONSOLE}} section [[Testing]]. In this section you can finally test your new service. Remember that Service TOUPPER_A is composed by three independent Operations:

'''Request'''
# Into the Service field select TOUPPER_A
# Into the System field select GVESB_TEST
# Into the Payload area insert the text to convert in uppercase
# Click Request

The '''FWD_TOUPPER_A''' is executed by {{GVESB}} [[GVForwards|JMS Forward]].

'''getReply'''
# Clear the Payload area
# Click getReply

When each test completes, the Testing view will be expanded for containing the GVBUFFER OUTPUT. In this case no properties have been defined so there are only be presents the main informations about the process (System, Service, Id, etc.). To view the service payload output click on ''Show as Text'' button. Standard fields and the detailed GVBuffer are described in the [[Testing#Data_input|Output File Name]] (the default location is <nowiki>$GV_HOME</nowiki>/log/TestOutput.txt).

In case of error or exceptions you can review the logs file present in the folder <nowiki>$GV_HOME</nowiki>/log/.

GVExample TOUPPER

2012-10-09T14:18:37Z

A.capaldo: /* How To */

==Description==

This simple example shows a simple [[Paradigms_of_communication|synchronous service]] and its configuration.
The service accept a string as input, then returns it converted to uppercase.

==How To==

[[File:NewVulconProject.jpg|thumb| New Vulcon Project]]As this might be our first example, the first step will be the creation of a new {{VULCON}} Project.
# From the Menu panel of Eclipse click File -> New -> Project. A new windows will be open containing the projects type.
# Select Vulcon -> "New Vulcon Project" item. Then click Next
# Set the project name and Location. We named the project GVEXAMPLE and choose a Location of your choice. Then click finish. The new {{VULCON}} project GVEXAMPLE has been created.

The preferred mode for creating a [[Service]] (at least its skeleton) is through the Service Wizard. Before using it you must first configure the test VCL plugin tho execute the uppercase conversion. So let's define a new [[Group]], [[System]] and [[Channel]], if you do not want to use those already present, and then start the Wizard.

From the core view:
# Right click the element Groups -> Insert after (or Insert before) -> Group. A new element Group will be created.
# Click on the Group new element and set the attribute ''id-group'' from the Properties View. We named it TEST_GROUP.
# Expand the GVSystems item.
# Right clicking on Systems, insert-after -> System. A new element System will be created.
# Set the [[System]] parameters in the [[VulCon_perspective|Properties panel]]. We named it GVESB_TEST
# You can insert a new [[Channel]] right clicking the new [[System]] element -> Insert after (or Insert before) -> Channel*. A new Channel element will be created
# Click on this new Channel element and set the property ''id_channel''. We named it TEST_CHANNEL
# Finally, insert the operation you need for the workflow. In this case a ''test-service-call''. Right clicking Channel -> Insert after -> [[test-service-call]]. A new element ''test-service-call'' will be created.
# Set the [[test-service-call]] attributes. From the properties view set the ''name'' attribute as ''test'' and the ''service'' attribute as ''toupper''.

[[File:NewServiceWizard.jpg|thumb|New {{GVESB}} Service Wizard]]Now we are able to use the Wizard.
# From the Core View of {{VULCON}}. Right click the element Services -> Wizard New Service
# A new window will be open where you can set the name of the Service you want to create, in this case we name it TOUPPER, and as Group, we use TEST_GROUP. You can also select the communication paradigm, for this example it will be [[Paradigms_of_communication#synchronous-synchronous|synchronous-synchronous]]. Click next.
# Set System as GVESB_TEST and Channel as TEST_CHANNEL. Then choose the Operation, in this case ''test''. Then finish.

[[File:TOUPPEREditor.jpg |thumb |TOUPPER flow]]As you can see from the core view, inside the Services element, a new Service named TOUPPER has been created. The editor will be opened automatically, showing the nodes involved in our [[Flow]].
* The [[Main_nodes|Start node]] sets the flow first node. In this case ''request''
* The [[Operations |Operation node]] ''request'' calls the ''test-service-call'' operation '''test''' and executes it.
* A [[Main_nodes|Check node]] named ''check_status'' is also inserted for controlling the success of the preceding node.
* If ''success'' flow passes to the [[Main_nodes|End node]] ''return_status''
* In case of Error, flow goes to the [[Main_nodes|End node]] ''return_error''. The difference with ''return_status'' is signed by the [[Palette|Connection]] with ''check_status'' Check node. In this case an [[Palette|Error Connection]] (the Red arrow) have been used.
* Save clicking the ''Save'' icon from the Core View

The GVCore.xml configuration file will be changed as follows:
* Into ''Groups'' element will be added the tag
<syntaxhighlight lang="XML">
<Group group-activation="on" id-group="TEST_GROUP"/>
</syntaxhighlight>
* Into ''Services'' element will be added the tag
<syntaxhighlight lang="XML">
<Service group-name="TEST_GROUP" id-service="TOUPPER" service-activation="on"
statistics="off">
<Operation name="RequestReply" operation-activation="on"
out-check-type="sys-svc-tid" type="operation">
<Description>VulCon generated Operation</Description>
<Participant id-channel="TEST_CHANNEL" id-system="GVESB_TEST"/>
<Flow first-node="request" point-x="50" point-y="150">
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
id="request" id-system="GVESB_TEST"
input="input_test" next-node-id="check_status"
op-type="call" operation-name="test"
output="output_test" point-x="200" point-y="150"
type="flow-node"/>
<GVNodeCheck class="it.greenvulcano.gvesb.core.flow.GVNodeCheck"
default-id="return_status" id="check_status"
input="output_test" on-exception-id="return_error"
op-type="check" point-x="350" point-y="150"
type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
id="return_status" op-type="end" output="output_test"
point-x="700" point-y="50" type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
id="return_error" op-type="end" output="output_test"
point-x="700" point-y="250" type="flow-node"/>
</Flow>
</Operation>
</Service>
</syntaxhighlight>
* Into ''Systems'' element will be added the tag
<syntaxhighlight lang="XML">
<System id-system="GVESB_TEST" system-activation="on">
<Channel id-channel="TEST_CHANNEL">
<test-service-call class="it.greenvulcano.gvesb.virtual.internal.TestServiceCall"
name="test" service="toupper" type="call"/>
</Channel>
</System>
</syntaxhighlight>

Now you are able to test your first {{VULCON}} Service from the {{L_GVCONSOLE}}. But first you need to export the configuration.

[[File:GVExamplesTOUPPER5.jpg|thumb|Exporting configuration]]Once the flow is correctly configured, the user can export the configuration and pass it to the {{GVESB}} import tool, in order to add into the {{GVESB}} the service just created.
# The Export function is available in the view "Project". Expand the project
# Before you proceed press F5 to refresh the file list.
# Right click the ''conf'' folder. It will open a drop-down list.
# Export your project as a VulCon project file (.zip).

===Testing with {{GVCONSOLE}}===

It is finally the time to test your project. To do that execute the following steps:

[[File:GVCONSOLEDeploy.jpg|thumb|Deploy new Service]]Suppose you have saved the {{VULCON}} project as <nowiki>REPG1.zip</nowiki>. To deploy the new Service follow this steps:
# [[Starting|Start {{GVESB}}]]
# [[GV_Console#Access|Access to the {{GVCONSOLE}}]].
# In the Deploy New Service section click Browse and select the file where you saved the {{VULCON}} configuration.
# Click Submit.

The section [[Deploy_Service|Deploy Services]] will be open. In this section you can select the services you want to deploy.
# Clicking on service TOUPPER a new view will be showed containing the file ''GVCore.xml'' present in local and on server side.
# Click Deploy. Now you can save the document and write some notes about it.
# Save the Document. By saving you will return to the [[Deploy Service]] section.

[[File:GVConsoleUtilityReload1.jpg|thumb|{{GVCONSOLE}} Utility section]]Now pass to the {{GVCONSOLE}} section [[Utility]].
# Click on [[Reload_Configuration|Reload configuration]]
# Select GVCore.xml and then Reload. A new windows will be open to confirm the operation
# Click OK.

[[File:GVConsoleTesting.jpg|thumb|{{GVCONSOLE}} Testing section]]Go to the {{GVCONSOLE}} section [[Testing]]. In this section you can finally test your new service:
# Into the Service field select TOUPPER
# Into the System field select GVESB_TEST (Optional)
# Into the Payload area insert the text to convert in uppercase
# Click RequestReply

When the service completes, the Testing view will be expanded for containing the GVBUFFER OUTPUT. In this case no properties have been defined so there are only be presents the main informations about the process (System, Service, Id, etc.). To view the service payload output click on ''Show as Text'' button. Standard fields and the detailed GVBuffer are described in the [[Testing#Data_input|Output File Name]] (the default location is <nowiki>$GV_HOME</nowiki>/log/TestOutput.txt).

In case of error or exceptions you can review the logs file present in the folder <nowiki>$GV_HOME</nowiki>/log/.

GVJade

2012-09-28T13:42:50Z

A.capaldo: /* Examples of messaging through GVJADE */

=='''GVJADE, a JADE integration in GreenVulcano'''==

==Introduction==

This Java application provides a direct JADE platform integration, which allows GreenVulcano to transparently interact with an inner set of JADE agents, using a direct 1-1 message transposition (internal ACL message to external XML, and viceversa).
The JADE technology could introduce a lighter and smarter way to interconnect between multiple legacy services and/or different GV instances.

==Description==

ATM, GVJADE allows to run different flow scenarios, involving internal (JADEd, using ACL messages) and external (GV's, using JMS queues) contexts.
These scenarios are a direct proof of true bridging between a JADE platform and GV context:

Scenario 1 : '''Messaging communication started from an external service/application (simulation of an external request to the inner agent):'''

* Through a simple JMS queue an external context may send an XML message, containing usual ACL message components such as: sender, receivers, action and content. (See section '''Example of messaging through JADE''' for a viable example)
* A bridging agent will receive the message and re-routes it to the infiltrated agent in ACL format
* Once the message is opened and used by the agent it prepares a proper response (following its internal logic) which will be sent back again to the bridging agent
* Bridging agent translates (this time the way around) the message in the exit format (XML) to the exit queue
* External context can now read response to its original message

Scenario 2 : '''Messaging communication started from inside the JADE platform agent (simulation of an inner update to deliver to the external context):'''

* An internal business agent, with a system update ready to be posted to the external application, sends it to the bridging agent
* The agent enroutes it to a proper queue, translated in XML code
* External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue
* Bridging agent pops the message from the queue and sends it back to originating business agent, in ACL format

Scenario 3 : '''GV messaging service running on a ditributed GV cluster'''

* With an XML registration message, a GV service can register through the proxy agent, which is meant to centralize communications
* Once the service registration appliance is accepted, the GV "route" is stored and the service can be reached from others GV instances/services simply contacting the proxy agent

Usual default service actions are also available, such as:
'''Start''', '''Update configuration''', '''Shutdown'''
are triggerable from the GV console.

==GVJADE service configuration==

First, extract "GVJADEAdapter-Configuration.xml" file (provided into the package zip file) into the \GreenV\xmlconfig\ path.
The XML file states JADE platform configuration as follows:

<GCJADEAdapterConfiguration>
<Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"></Engine>
<Agents>
<Agent name="PingAgent" class="examples.PingAgent.PingAgent"/>
</Agents>
</GCJADEAdapterConfiguration>

Attributes optional to be changed are
*"local-port", which needs to be different from any used by GV, since its a hosting port)
*"gui", which allows to run other agents, such as Sniffer, useful to monitor communication between platforms and agents
*"Agent name", in order to add any other eventual agent class
Other attributes are not to be edited.

To add GVJADE service to GV enumeration edit and add the following:

<generic-initializer class="main.java.test.jmx.RegisterGVJADEAdapter" target="${{jboss.server.name}}" type="initializer"/>

to \GreenV\xmlconfig\gv-jmx.xml file, under the "Initializers" tag.

Also add

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

in \GreenV\application\deploy\gvesb-mq-destinations-service.xml, under the "server" tag.

==Examples of messaging through GVJADE==

*Applying scenario 1
Configure a process to send a JMS message to the "''GV_JADE_Response_Queue''" queue, serviced under GV, with the following XML code:

<XMLMessage><sender>GVapp1</sender><receivers><receiver><name>PingAgent@Main_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>ping</content></XMLMessage>

This, as previously shown in case scenario 1, will trigger GVJADE processing the message to the inner JADE agent ("''PingAgent''").
The expected result to the ''REQUEST'':"''ping''" message can be received through the "''GV_JADE_Request_Queue''" queue, which will be an ''INFORM'':"''pong''" action.

*Applying scenario 2
In order to trigger scenario 2 shown above a JADE platform must be run (via terminal console or IDE such as Eclipse).
Through the platform run a simple agent with send/response capabilities (such as default ''DummyAgent'').
Prepare a message to send with:

- address to reach as the GVJADE address/agent (address is the platform one readable from the GVJADE output, while the agent name is the bridging one: "'''JadeToGvAgent'''")

- communicative act configured as ''REQUEST''

- content edited a simple "''ping''" (a simple content to update the internal status to the outside world)

Then press to send the message.

An ''INFORM'':"''pong''" message will be received from the original sender agent, reporting sort of a "course of action" to follow about the initial update.

*Applying scenario 3
In order to gain accessibility to cluster based messaging between different GV instances a REGISTRATION kind of message needs to be sent to the ingoing queue from a certain GVserv1 service:

<XMLMessage><sender><name>GVserv1</name></sender><receivers><receiver><name>''ProxyAgent@Proxy_GV_Container''</name></receiver></receivers><comm action="REQUEST"/><content>'''[REGISTRATION]'''</content>
</XMLMessage>

Once its registration process is done, GVserv1 will be reachable through the GV clustering.
For instance, a GVserv2 (which has been previously been registered) can message GVserv1 by sending a simple XML message, formatted as before:

<XMLMessage><sender><name>GVserv2</name></sender><receivers><receiver><name>''GVserv1''</name></receiver></receivers><comm action="REQUEST"/><content>'''Hi, im a service like you. Pleased to meet you. :-)'''</content>
</XMLMessage>

The Proxy agent will recognize the receiver name previously registered, and will be able to use it with the properly stored route (which is a simple pair : ''gateway/bridging agent'' + ''http GV machine address'').
Once received, GVserv1 will be able to respond simply sending a message formatted with "GVserv2" as receiver, which has been registered on the proxy.
The ''gateway/bridging agent'' stated before is an ''hybrid bordering agent'', capable of "speaking" 2 different languages (XML and ACL Fipa): each GV instance/route owns one of these, and its crossed through the messaging phase.

Each messaging phase is meant to cross 2 bridging agents: in the case pictured above message will go from GVserv2 to one bridging agent (owned by the GVserv2 context), then to the Proxy Agent (which will "query" the receiver into its routing map). Proxy agent will "query" receiver name into its routing map and then reroutes message to the proper second bridging agent (owned by the GVserv1 context), down to the GVserv1.

GVJade

2012-09-28T13:42:16Z

A.capaldo: /* Examples of messaging through GVJADE */

GVJade

2012-09-28T13:41:37Z

A.capaldo: /* Examples of messaging through GVJADE */

=='''GVJADE, a JADE integration in GreenVulcano'''==

==Introduction==

This Java application provides a direct JADE platform integration, which allows GreenVulcano to transparently interact with an inner set of JADE agents, using a direct 1-1 message transposition (internal ACL message to external XML, and viceversa).
The JADE technology could introduce a lighter and smarter way to interconnect between multiple legacy services and/or different GV instances.

==Description==

ATM, GVJADE allows to run different flow scenarios, involving internal (JADEd, using ACL messages) and external (GV's, using JMS queues) contexts.
These scenarios are a direct proof of true bridging between a JADE platform and GV context:

Scenario 1 : '''Messaging communication started from an external service/application (simulation of an external request to the inner agent):'''

* Through a simple JMS queue an external context may send an XML message, containing usual ACL message components such as: sender, receivers, action and content. (See section '''Example of messaging through JADE''' for a viable example)
* A bridging agent will receive the message and re-routes it to the infiltrated agent in ACL format
* Once the message is opened and used by the agent it prepares a proper response (following its internal logic) which will be sent back again to the bridging agent
* Bridging agent translates (this time the way around) the message in the exit format (XML) to the exit queue
* External context can now read response to its original message

Scenario 2 : '''Messaging communication started from inside the JADE platform agent (simulation of an inner update to deliver to the external context):'''

* An internal business agent, with a system update ready to be posted to the external application, sends it to the bridging agent
* The agent enroutes it to a proper queue, translated in XML code
* External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue
* Bridging agent pops the message from the queue and sends it back to originating business agent, in ACL format

Scenario 3 : '''GV messaging service running on a ditributed GV cluster'''

* With an XML registration message, a GV service can register through the proxy agent, which is meant to centralize communications
* Once the service registration appliance is accepted, the GV "route" is stored and the service can be reached from others GV instances/services simply contacting the proxy agent

Usual default service actions are also available, such as:
'''Start''', '''Update configuration''', '''Shutdown'''
are triggerable from the GV console.

==GVJADE service configuration==

First, extract "GVJADEAdapter-Configuration.xml" file (provided into the package zip file) into the \GreenV\xmlconfig\ path.
The XML file states JADE platform configuration as follows:

<GCJADEAdapterConfiguration>
<Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"></Engine>
<Agents>
<Agent name="PingAgent" class="examples.PingAgent.PingAgent"/>
</Agents>
</GCJADEAdapterConfiguration>

Attributes optional to be changed are
*"local-port", which needs to be different from any used by GV, since its a hosting port)
*"gui", which allows to run other agents, such as Sniffer, useful to monitor communication between platforms and agents
*"Agent name", in order to add any other eventual agent class
Other attributes are not to be edited.

To add GVJADE service to GV enumeration edit and add the following:

<generic-initializer class="main.java.test.jmx.RegisterGVJADEAdapter" target="${{jboss.server.name}}" type="initializer"/>

to \GreenV\xmlconfig\gv-jmx.xml file, under the "Initializers" tag.

Also add

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

in \GreenV\application\deploy\gvesb-mq-destinations-service.xml, under the "server" tag.

==Examples of messaging through GVJADE==

*Applying scenario 1
Configure a process to send a JMS message to the "''GV_JADE_Response_Queue''" queue, serviced under GV, with the following XML code:

<XMLMessage><sender>GVapp1</sender><receivers><receiver><name>PingAgent@Main_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>ping</content></XMLMessage>

This, as previously shown in case scenario 1, will trigger GVJADE processing the message to the inner JADE agent ("''PingAgent''").
The expected result to the ''REQUEST'':"''ping''" message can be received through the "''GV_JADE_Request_Queue''" queue, which will be an ''INFORM'':"''pong''" action.

*Applying scenario 2
In order to trigger scenario 2 shown above a JADE platform must be run (via terminal console or IDE such as Eclipse).
Through the platform run a simple agent with send/response capabilities (such as default ''DummyAgent'').
Prepare a message to send with:

- address to reach as the GVJADE address/agent (address is the platform one readable from the GVJADE output, while the agent name is the bridging one: "'''JadeToGvAgent'''")

- communicative act configured as ''REQUEST''

- content edited a simple "''ping''" (a simple content to update the internal status to the outside world)

Then press to send the message.

An ''INFORM'':"''pong''" message will be received from the original sender agent, reporting sort of a "course of action" to follow about the initial update.

*Applying scenario 3
In order to gain accessibility to cluster based messaging between different GV instances a REGISTRATION kind of message needs to be sent to the ingoing queue from a certain GVserv1 service:

<XMLMessage><sender><name>GVserv1</name></sender><receivers><receiver><name>''ProxyAgent@Proxy_GV_Container''</name></receiver></receivers><comm action="REQUEST"/><content>'''[REGISTRATION]'''</content>
</XMLMessage>

Once its registration process is done, GVserv1 will be reachable through the GV clustering.
For instance, a GVserv2 (which has been previously been registered) can message GVserv1 by sending a simple XML message, formatted as before:

<XMLMessage><sender><name>GVserv2</name></sender><receivers><receiver><name>''GVserv1''</name></receiver></receivers><comm action="REQUEST"/><content>'''Hi, im a service like you. Pleased to meet you. :-)'''</content>
</XMLMessage>

The Proxy agent will recognize the receiver name previously registered, and will be able to use it with the properly stored route (which is a simple pair : ''gateway/bridging agent'' + ''http GV machine address'').
Once received, GVserv1 will be able to respond simply sending a message formatted with "GVserv2" as receiver, which has been registered on the proxy.
The ''gateway/bridging agent'' stated before is an ''hybrid bordering agent'', capable of "speaking" 2 different languages (XML and ACL Fipa): each GV instance/route owns one of these, and its crossed through the messaging phase.

Each messaging phase is meant to cross 2 bridging agents: in the case pictured above message will go from GVserv2 to one bridging agent (owned by the GVserv2 context), then to the Proxy Agent (which will "query" the receiving into its routing map). Proxy agent will "query" receiver name into its routing map and then reroutes message to the proper second bridging agent (owned by the GVserv1 context), down to the GVserv1.

GVJade

2012-09-28T13:40:58Z

A.capaldo: /* Examples of messaging through GVJADE */

=='''GVJADE, a JADE integration in GreenVulcano'''==

==Introduction==

This Java application provides a direct JADE platform integration, which allows GreenVulcano to transparently interact with an inner set of JADE agents, using a direct 1-1 message transposition (internal ACL message to external XML, and viceversa).
The JADE technology could introduce a lighter and smarter way to interconnect between multiple legacy services and/or different GV instances.

==Description==

ATM, GVJADE allows to run different flow scenarios, involving internal (JADEd, using ACL messages) and external (GV's, using JMS queues) contexts.
These scenarios are a direct proof of true bridging between a JADE platform and GV context:

Scenario 1 : '''Messaging communication started from an external service/application (simulation of an external request to the inner agent):'''

* Through a simple JMS queue an external context may send an XML message, containing usual ACL message components such as: sender, receivers, action and content. (See section '''Example of messaging through JADE''' for a viable example)
* A bridging agent will receive the message and re-routes it to the infiltrated agent in ACL format
* Once the message is opened and used by the agent it prepares a proper response (following its internal logic) which will be sent back again to the bridging agent
* Bridging agent translates (this time the way around) the message in the exit format (XML) to the exit queue
* External context can now read response to its original message

Scenario 2 : '''Messaging communication started from inside the JADE platform agent (simulation of an inner update to deliver to the external context):'''

* An internal business agent, with a system update ready to be posted to the external application, sends it to the bridging agent
* The agent enroutes it to a proper queue, translated in XML code
* External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue
* Bridging agent pops the message from the queue and sends it back to originating business agent, in ACL format

Scenario 3 : '''GV messaging service running on a ditributed GV cluster'''

* With an XML registration message, a GV service can register through the proxy agent, which is meant to centralize communications
* Once the service registration appliance is accepted, the GV "route" is stored and the service can be reached from others GV instances/services simply contacting the proxy agent

Usual default service actions are also available, such as:
'''Start''', '''Update configuration''', '''Shutdown'''
are triggerable from the GV console.

==GVJADE service configuration==

First, extract "GVJADEAdapter-Configuration.xml" file (provided into the package zip file) into the \GreenV\xmlconfig\ path.
The XML file states JADE platform configuration as follows:

<GCJADEAdapterConfiguration>
<Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"></Engine>
<Agents>
<Agent name="PingAgent" class="examples.PingAgent.PingAgent"/>
</Agents>
</GCJADEAdapterConfiguration>

Attributes optional to be changed are
*"local-port", which needs to be different from any used by GV, since its a hosting port)
*"gui", which allows to run other agents, such as Sniffer, useful to monitor communication between platforms and agents
*"Agent name", in order to add any other eventual agent class
Other attributes are not to be edited.

To add GVJADE service to GV enumeration edit and add the following:

<generic-initializer class="main.java.test.jmx.RegisterGVJADEAdapter" target="${{jboss.server.name}}" type="initializer"/>

to \GreenV\xmlconfig\gv-jmx.xml file, under the "Initializers" tag.

Also add

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

in \GreenV\application\deploy\gvesb-mq-destinations-service.xml, under the "server" tag.

==Examples of messaging through GVJADE==

*Applying scenario 1
Configure a process to send a JMS message to the "''GV_JADE_Response_Queue''" queue, serviced under GV, with the following XML code:

<XMLMessage><sender>GVapp1</sender><receivers><receiver><name>PingAgent@Main_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>ping</content></XMLMessage>

This, as previously shown in case scenario 1, will trigger GVJADE processing the message to the inner JADE agent ("''PingAgent''").
The expected result to the ''REQUEST'':"''ping''" message can be received through the "''GV_JADE_Request_Queue''" queue, which will be an ''INFORM'':"''pong''" action.

*Applying scenario 2
In order to trigger scenario 2 shown above a JADE platform must be run (via terminal console or IDE such as Eclipse).
Through the platform run a simple agent with send/response capabilities (such as default ''DummyAgent'').
Prepare a message to send with:

- address to reach as the GVJADE address/agent (address is the platform one readable from the GVJADE output, while the agent name is the bridging one: "'''JadeToGvAgent'''")

- communicative act configured as ''REQUEST''

- content edited a simple "''ping''" (a simple content to update the internal status to the outside world)

Then press to send the message.

An ''INFORM'':"''pong''" message will be received from the original sender agent, reporting sort of a "course of action" to follow about the initial update.

*Applying scenario 3
In order to gain accessibility to cluster based messaging between different GV instances a REGISTRATION kind of message needs to be sent to the ingoing queue from a certain GVserv1 service:

<XMLMessage><sender><name>GVserv1</name></sender><receivers><receiver><name>''ProxyAgent@Proxy_GV_Container''</name></receiver></receivers><comm action="REQUEST"/><content>'''[REGISTRATION]'''</content>
</XMLMessage>

Once its registration process is done, GVserv1 will be reachable through the GV clustering.
For instance, a GVserv2 (which has been previously been registered) can message GVserv1 by sending a simple XML message, formatted as before:

<XMLMessage><sender><name>GVserv2</name></sender><receivers><receiver><name>''GVserv1''</name></receiver></receivers><comm action="REQUEST"/><content>'''Hi, im a service like you. Pleased to meet you. :-)'''</content>
</XMLMessage>

The Proxy agent will recognize the receiver name previously registered, and will be able to use it with the properly stored route (which is a simple pair : ''gateway/bridging agent'' + ''http GV machine address'').
Once received, GVserv1 will be able to respond simply sending a message formatted with "GVserv2" as receiver, which has been registered on the proxy.
The ''gateway/bridging agent'' stated before is an ''hybrid bordering agent'', capable of "speaking" 2 different languages (XML and ACL Fipa): each GV instance/route owns one of these, and its crossed through the messaging phase.
Each messaging phase is meant to cross 2 bridging agents: in the case pictured above message will go from GVserv2 to one bridging agent (owned by the GVserv2 context), then to the Proxy Agent (which will "query" the receiving into its routing map). Proxy agent will "query" receiver name into its routing map and then reroutes message to the proper second bridging agent (owned by the GVserv1 context), down to the GVserv1.

GVJade

2012-09-28T13:39:58Z

A.capaldo: /* Examples of messaging through GVJADE */

=='''GVJADE, a JADE integration in GreenVulcano'''==

==Introduction==

This Java application provides a direct JADE platform integration, which allows GreenVulcano to transparently interact with an inner set of JADE agents, using a direct 1-1 message transposition (internal ACL message to external XML, and viceversa).
The JADE technology could introduce a lighter and smarter way to interconnect between multiple legacy services and/or different GV instances.

==Description==

ATM, GVJADE allows to run different flow scenarios, involving internal (JADEd, using ACL messages) and external (GV's, using JMS queues) contexts.
These scenarios are a direct proof of true bridging between a JADE platform and GV context:

Scenario 1 : '''Messaging communication started from an external service/application (simulation of an external request to the inner agent):'''

* Through a simple JMS queue an external context may send an XML message, containing usual ACL message components such as: sender, receivers, action and content. (See section '''Example of messaging through JADE''' for a viable example)
* A bridging agent will receive the message and re-routes it to the infiltrated agent in ACL format
* Once the message is opened and used by the agent it prepares a proper response (following its internal logic) which will be sent back again to the bridging agent
* Bridging agent translates (this time the way around) the message in the exit format (XML) to the exit queue
* External context can now read response to its original message

Scenario 2 : '''Messaging communication started from inside the JADE platform agent (simulation of an inner update to deliver to the external context):'''

* An internal business agent, with a system update ready to be posted to the external application, sends it to the bridging agent
* The agent enroutes it to a proper queue, translated in XML code
* External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue
* Bridging agent pops the message from the queue and sends it back to originating business agent, in ACL format

Scenario 3 : '''GV messaging service running on a ditributed GV cluster'''

* With an XML registration message, a GV service can register through the proxy agent, which is meant to centralize communications
* Once the service registration appliance is accepted, the GV "route" is stored and the service can be reached from others GV instances/services simply contacting the proxy agent

Usual default service actions are also available, such as:
'''Start''', '''Update configuration''', '''Shutdown'''
are triggerable from the GV console.

==GVJADE service configuration==

First, extract "GVJADEAdapter-Configuration.xml" file (provided into the package zip file) into the \GreenV\xmlconfig\ path.
The XML file states JADE platform configuration as follows:

<GCJADEAdapterConfiguration>
<Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"></Engine>
<Agents>
<Agent name="PingAgent" class="examples.PingAgent.PingAgent"/>
</Agents>
</GCJADEAdapterConfiguration>

Attributes optional to be changed are
*"local-port", which needs to be different from any used by GV, since its a hosting port)
*"gui", which allows to run other agents, such as Sniffer, useful to monitor communication between platforms and agents
*"Agent name", in order to add any other eventual agent class
Other attributes are not to be edited.

To add GVJADE service to GV enumeration edit and add the following:

<generic-initializer class="main.java.test.jmx.RegisterGVJADEAdapter" target="${{jboss.server.name}}" type="initializer"/>

to \GreenV\xmlconfig\gv-jmx.xml file, under the "Initializers" tag.

Also add

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

in \GreenV\application\deploy\gvesb-mq-destinations-service.xml, under the "server" tag.

==Examples of messaging through GVJADE==

*Applying scenario 1
Configure a process to send a JMS message to the "''GV_JADE_Response_Queue''" queue, serviced under GV, with the following XML code:

<XMLMessage><sender>GVapp1</sender><receivers><receiver><name>PingAgent@Main_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>ping</content></XMLMessage>

This, as previously shown in case scenario 1, will trigger GVJADE processing the message to the inner JADE agent ("''PingAgent''").
The expected result to the ''REQUEST'':"''ping''" message can be received through the "''GV_JADE_Request_Queue''" queue, which will be an ''INFORM'':"''pong''" action.

*Applying scenario 2
In order to trigger scenario 2 shown above a JADE platform must be run (via terminal console or IDE such as Eclipse).
Through the platform run a simple agent with send/response capabilities (such as default ''DummyAgent'').
Prepare a message to send with:

- address to reach as the GVJADE address/agent (address is the platform one readable from the GVJADE output, while the agent name is the bridging one: "'''JadeToGvAgent'''")

- communicative act configured as ''REQUEST''

- content edited a simple "''ping''" (a simple content to update the internal status to the outside world)

Then press to send the message.

An ''INFORM'':"''pong''" message will be received from the original sender agent, reporting sort of a "course of action" to follow about the initial update.

*Applying scenario 3
In order to gain accessibility to cluster based messaging between different GV instances a REGISTRATION kind of message needs to be sent to the ingoing queue from a certain GVserv1 service:

<XMLMessage><sender><name>GVserv1</name></sender><receivers><receiver><name>''ProxyAgent@Proxy_GV_Container''</name></receiver></receivers><comm action="REQUEST"/><content>'''[REGISTRATION]'''</content>
</XMLMessage>

Once its registration process is done, GVserv1 will be reachable through the GV clustering.
For instance, a GVserv2 (which has been previously been registered) can message GVserv1 by sending a simple XML message, formatted as before:

<XMLMessage><sender><name>GVserv2</name></sender><receivers><receiver><name>''GVserv1''</name></receiver></receivers><comm action="REQUEST"/><content>'''Hi, im a service like you. Pleased to meet you. :-)'''</content>
</XMLMessage>

The Proxy agent will recognize the receiver name previously registered, and will be able to use it with the properly stored route (which is a simple pair like : ''gateway/bridging agent'' + ''http GV machine address'')
Once received, GVserv1 will be able to respond simply sending a message formatted with "GVserv2" as receiver, which has been registered on the proxy.
The ''gateway/bridging agent'' stated before is an ''hybrid bordering agent'', capable of "speaking" 2 different languages (XML and ACL Fipa): each GV instance/route owns one of these, and its crossed through the messaging phase.
Each messaging phase is meant to cross 2 bridging agents: in the case pictured above message will go from GVserv2 to one bridging agent (owned by the GVserv2 context), then to the Proxy Agent (which will "query" the receiving into its routing map). Proxy agent will "query" receiver name into its routing map and then reroutes message to the proper second bridging agent (owned by the GVserv1 context), down to the GVserv1.

GVJade

2012-09-28T13:39:24Z

A.capaldo: /* Examples of messaging through GVJADE */

=='''GVJADE, a JADE integration in GreenVulcano'''==

==Introduction==

This Java application provides a direct JADE platform integration, which allows GreenVulcano to transparently interact with an inner set of JADE agents, using a direct 1-1 message transposition (internal ACL message to external XML, and viceversa).
The JADE technology could introduce a lighter and smarter way to interconnect between multiple legacy services and/or different GV instances.

==Description==

ATM, GVJADE allows to run different flow scenarios, involving internal (JADEd, using ACL messages) and external (GV's, using JMS queues) contexts.
These scenarios are a direct proof of true bridging between a JADE platform and GV context:

Scenario 1 : '''Messaging communication started from an external service/application (simulation of an external request to the inner agent):'''

* Through a simple JMS queue an external context may send an XML message, containing usual ACL message components such as: sender, receivers, action and content. (See section '''Example of messaging through JADE''' for a viable example)
* A bridging agent will receive the message and re-routes it to the infiltrated agent in ACL format
* Once the message is opened and used by the agent it prepares a proper response (following its internal logic) which will be sent back again to the bridging agent
* Bridging agent translates (this time the way around) the message in the exit format (XML) to the exit queue
* External context can now read response to its original message

Scenario 2 : '''Messaging communication started from inside the JADE platform agent (simulation of an inner update to deliver to the external context):'''

* An internal business agent, with a system update ready to be posted to the external application, sends it to the bridging agent
* The agent enroutes it to a proper queue, translated in XML code
* External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue
* Bridging agent pops the message from the queue and sends it back to originating business agent, in ACL format

Scenario 3 : '''GV messaging service running on a ditributed GV cluster'''

* With an XML registration message, a GV service can register through the proxy agent, which is meant to centralize communications
* Once the service registration appliance is accepted, the GV "route" is stored and the service can be reached from others GV instances/services simply contacting the proxy agent

Usual default service actions are also available, such as:
'''Start''', '''Update configuration''', '''Shutdown'''
are triggerable from the GV console.

==GVJADE service configuration==

First, extract "GVJADEAdapter-Configuration.xml" file (provided into the package zip file) into the \GreenV\xmlconfig\ path.
The XML file states JADE platform configuration as follows:

<GCJADEAdapterConfiguration>
<Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"></Engine>
<Agents>
<Agent name="PingAgent" class="examples.PingAgent.PingAgent"/>
</Agents>
</GCJADEAdapterConfiguration>

Attributes optional to be changed are
*"local-port", which needs to be different from any used by GV, since its a hosting port)
*"gui", which allows to run other agents, such as Sniffer, useful to monitor communication between platforms and agents
*"Agent name", in order to add any other eventual agent class
Other attributes are not to be edited.

To add GVJADE service to GV enumeration edit and add the following:

<generic-initializer class="main.java.test.jmx.RegisterGVJADEAdapter" target="${{jboss.server.name}}" type="initializer"/>

to \GreenV\xmlconfig\gv-jmx.xml file, under the "Initializers" tag.

Also add

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

in \GreenV\application\deploy\gvesb-mq-destinations-service.xml, under the "server" tag.

==Examples of messaging through GVJADE==

*Applying scenario 1
Configure a process to send a JMS message to the "''GV_JADE_Response_Queue''" queue, serviced under GV, with the following XML code:

<XMLMessage><sender>GVapp1</sender><receivers><receiver><name>PingAgent@Main_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>ping</content></XMLMessage>

This, as previously shown in case scenario 1, will trigger GVJADE processing the message to the inner JADE agent ("''PingAgent''").
The expected result to the ''REQUEST'':"''ping''" message can be received through the "''GV_JADE_Request_Queue''" queue, which will be an ''INFORM'':"''pong''" action.

*Applying scenario 2
In order to trigger scenario 2 shown above a JADE platform must be run (via terminal console or IDE such as Eclipse).
Through the platform run a simple agent with send/response capabilities (such as default ''DummyAgent'').
Prepare a message to send with:

- address to reach as the GVJADE address/agent (address is the platform one readable from the GVJADE output, while the agent name is the bridging one: "'''JadeToGvAgent'''")

- communicative act configured as ''REQUEST''

- content edited a simple "''ping''" (a simple content to update the internal status to the outside world)

Then press to send the message.

An ''INFORM'':"''pong''" message will be received from the original sender agent, reporting sort of a "course of action" to follow about the initial update.

*Applying scenario 3
In order to gain accessibility to cluster based messaging between different GV instances a REGISTRATION kind of message needs to be sent to the ingoing queue from a certain GVserv1 service:

<XMLMessage><sender><name>GVserv1</name></sender><receivers><receiver><name>''ProxyAgent@Proxy_GV_Container''</name></receiver></receivers><comm action="REQUEST"/><content>'''[REGISTRATION]'''</content>
</XMLMessage>

Once its registration process is done, GVserv1 will be reachable through the GV clustering.
For instance, a GVserv2 (which has been previously been registered) can message GVserv1 by sending a simple XML message, formatted as before:

<XMLMessage><sender><name>GVserv2</name></sender><receivers><receiver><name>''GVserv1''</name></receiver></receivers><comm action="REQUEST"/><content>'''Hi, im a service like you. Pleased to meet you. :-)'''</content>
</XMLMessage>

The Proxy agent will recognize the receiver name previously registered, and will be able to use it with the properly stored route (which is a simple pair like : ''gateway/bridging agent'' + ''http GV machine address'')
Once received, GVserv1 will be able to respond simply sending a message formatted with "GVserv2" as receiver, which has been registered on the proxy.
The ''gateway/bridging agent'' stated before is an ''hybrid bordering agent'', capable of "speaking" 2 different languages (XML and ACL Fipa): each GV instance/route owns one of these, and its crossed through the messaging phase.
Each messaging phase is meant to cross 2 bridging agents: in the case pictured above message will go from GVserv2 to one bridging agent (owned by the GVserv2 context), then to the Proxy Agent (which will "query" the receiving into its routing map). Proxy agent will "query" receiver name into its routing map and then reroutes message to the proper second bridging agent (owned by the GVserv1 context), down to the GVserv1.

GVJade

2012-09-28T13:15:23Z

A.capaldo: /* Description */

GVJade

2012-09-28T13:15:02Z

A.capaldo: /* Description */

=='''GVJADE, a JADE integration in GreenVulcano'''==

==Introduction==

This Java application provides a direct JADE platform integration, which allows GreenVulcano to transparently interact with an inner set of JADE agents, using a direct 1-1 message transposition (internal ACL message to external XML, and viceversa).
The JADE technology could introduce a lighter and smarter way to interconnect between multiple legacy services and/or different GV instances.

==Description==

ATM, GVJADE allows to run different flow scenarios, involving internal (JADEd, using ACL messages) and external (GV's, using JMS queues) contexts.
These scenarios are a direct proof of true bridging between a JADE platform and GV context:

Scenario 1 : '''Messaging communication started from an external service/application (simulation of an external request to the inner agent):'''

* Through a simple JMS queue an external context may send an XML message, containing usual ACL message components such as: sender, receivers, action and content. (See section '''Example of messaging through JADE''' for a viable example)
* A bridging agent will receive the message and re-routes it to the infiltrated agent in ACL format
* Once the message is opened and used by the agent it prepares a proper response (following its internal logic) which will be sent back again to the bridging agent
* Bridging agent translates (this time the way around) the message in the exit format (XML) to the exit queue
* External context can now read response to its original message

Scenario 2 : '''Messaging communication started from inside the JADE platform agent (simulation of an inner update to deliver to the external context):'''

* An internal business agent, with a system update ready to be posted to the external application, sends it to the bridging agent
* The agent enroutes it to a proper queue, translated in XML code
* External application, waiting for the update, finds and uses it, also preparing a proper response in XML and sending it to another queue
* Bridging agent pops the message from the queue and sends it back to originating business agent, in ACL format

Scenario 3 : GV messaging service running on a ditributed GV cluster

* With an XML registration message, a GV service can register through the proxy agent, which is meant to centralize communications
* Once the service registration appliance is accepted, the GV "route" is stored and the service can be reached from others GV instances/services simply contacting the proxy agent

Usual default service actions are also available, such as:
'''Start''', '''Update configuration''', '''Shutdown'''
are triggerable from the GV console.

==GVJADE service configuration==

First, extract "GVJADEAdapter-Configuration.xml" file (provided into the package zip file) into the \GreenV\xmlconfig\ path.
The XML file states JADE platform configuration as follows:

<GCJADEAdapterConfiguration>
<Engine main="true" local-port="1500" gui="false" dump-options="true" no-display="true" platform-id="Main_GV_Container" nomtp="false"></Engine>
<Agents>
<Agent name="PingAgent" class="examples.PingAgent.PingAgent"/>
</Agents>
</GCJADEAdapterConfiguration>

Attributes optional to be changed are
*"local-port", which needs to be different from any used by GV, since its a hosting port)
*"gui", which allows to run other agents, such as Sniffer, useful to monitor communication between platforms and agents
*"Agent name", in order to add any other eventual agent class
Other attributes are not to be edited.

To add GVJADE service to GV enumeration edit and add the following:

<generic-initializer class="main.java.test.jmx.RegisterGVJADEAdapter" target="${{jboss.server.name}}" type="initializer"/>

to \GreenV\xmlconfig\gv-jmx.xml file, under the "Initializers" tag.

Also add

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JADE_GV_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/JADE_GV_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Request_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Request_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=GV_JADE_Response_Queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
<attribute name="JNDIName">gvesb/jms/queue/GV_JADE_Response_Queue</attribute>
<attribute name="RedeliveryDelay">60000</attribute>
<attribute name="MaxDeliveryAttempts">100</attribute>
</mbean>

in \GreenV\application\deploy\gvesb-mq-destinations-service.xml, under the "server" tag.

==Examples of messaging through GVJADE==

*Applying scenario 1
Configure a process to send a JMS message to the "''GV_JADE_Response_Queue''" queue, serviced under GV, with the following XML code:

<XMLMessage><sender>GVapp1</sender><receivers><receiver><name>PingAgent@Main_GV_Container</name></receiver></receivers><comm action="REQUEST"/><content>ping</content></XMLMessage>

This, as previously shown in case scenario 1, will trigger GVJADE processing the message to the inner JADE agent ("''PingAgent''").
The expected result to the ''REQUEST'':"''ping''" message can be received through the "''GV_JADE_Request_Queue''" queue, which will be an ''INFORM'':"''pong''" action.

*Applying scenario 2
In order to trigger scenario 2 shown above a JADE platform must be run (via terminal console or IDE such as Eclipse).
Through the platform run a simple agent with send/response capabilities (such as default ''DummyAgent'').
Prepare a message to send with:

- address to reach as the GVJADE address/agent (address is the platform one readable from the GVJADE output, while the agent name is the bridging one: "'''JadeToGvAgent'''")

- communicative act configured as ''REQUEST''

- content edited a simple "''ping''" (a simple content to update the internal status to the outside world)

Then press to send the message.

An ''INFORM'':"''pong''" message will be received from the original sender agent, reporting sort of a "course of action" to follow about the initial update.