GreenVulcano Wiki - User contributions [en]

Roadmap

2012-09-03T13:38:50Z

G.iannello: /* Version 3.4 (Q2 2013) */

===Road Map===

The engagement of GreenVulcano is to evolve the integration platform basing on the following criteria:

* Requests / Contributions from the community
* Specific needs of customers and developers
* Contributions of the partners / System Integrators

Our team adds its experience and expertise by offering innovative solutions in line with the vision that has always pushed us since our birth: simplicity and robustness.

GreenVulcano remains thus attached to the "real world", not in any way feeling the need to pursue or chasing at all costs the latest fashion trends of other products in the market.

The Roadmap is updated by our software architects and checked every six months.

===Version 3.2 (Q1 2012)===

1) “Sub Flow” management

2) BPEL Flows management

3) Every-component-Wizard on [[VulCon]] designer

4) Grafical Data Mapper

5) Drools integration

6) HL7 Adapter

7) New Wiki

===Version 3.3 (Q3 2012)===

1) Parallel flows

2) Grafical Try/Catch

3) Deploy and test from VulCon

===Version 3.4 (Q2 2013)===

1) Grafical Debugger

2) Service High availability and GV propietary cluster management implementation (currently managed by application server)

3) EJB 3.0 and Spring based version release

GVCoreEJBClientExamples

2012-08-03T15:04:56Z

G.iannello:

In the Client package are provided two sample applications:
* a stand alone java class
* a Tomcat web application

For each example is provided an Ant build script to automate the compilation and packaging.

----
The stand alone java class is in the examples/client folder and illustrates the invocation of synchronous/asynchronous services. 
The "ant test" task compiles and runs the client test.

----
The Tomcat web application builds a .war file that can be deployed on a Tomcat web server. 
At the url http://localhost:8080/testgvc/index.jsp can be used a HTML page that allows you to set the parameters to invoke a {{GVESB}} service.

Core EJB Client

2012-08-03T15:03:50Z

G.iannello:

The Core EJB Client is a simple utility that enable a class to invoke {{GVESB}} services through the Core EJB Adapter. The Client uses a properties file containing the parameters to connect to the (remote) {{GVESB}} server JNDI tree.

The client interface is [[GVCoreEJBClient]] class.

The properties file, ex. jndi.properties, must be configured through the following system property: -Dit.greenvulcano.gvesb.core.ejb.client.jndi="path to /jndi.properties" 
The file is polled for change every 5 minutes.

From [http://commons.apache.org/ognl/language-guide.html here] the client package can be downloaded.

The package contains the following directories:
* lib : the client and GV support libraries
* extra-lib : JBoss 5.1 client libraries
* [[GVCoreEJBClientExamples|examples]] : stand-alone and Tomcat web application examples

For each example an Ant build script to automate the compilation and packaging is provided.

Client

2012-03-01T15:51:29Z

G.iannello: /* Description */

==Description==

Defines a service client. Before you can designate a system as a "client of a service", you must configure the [[system]] in the Systems section.

Note that client means "the system used by field 'system' of [[GVBuffer]]" (the data buffer for {{GVESB}}), and this value can be used in flows routing conditions.

This field contains the name of the client system that began the transaction. Even in the delivery of responses by server systems (Call-Back), this field will contain the name of the client that made the request.

Installer Overview

2012-02-23T17:24:36Z

G.iannello:

The installer allows you to run in two different modes:

# GUI mode
# Console mode

'''GUI mode'''

In GUI mode, the installer presents a wizard that allows you to make your choices about product configuration and component selection. 
When you start the installer by simply execute it, GUI mode is used.

'''Console mode'''

Console mode allows you to run the installer from a command line. 
It is useful on system where a graphic environment is not available.

'''Required and Optional Third Party Components'''

Depending on the tasks you wish to perform, you must install one or more other third party components.

''Required and Optional Components''

{| class="gvtable"
! Component
! Purpose
|-
| Oracle JDK 1.6.0 or higher
| Required. Oracle JDK 1.6.0 is required to start the GreenVulcano Universal Installer.
|-
| JBoss 5.1.0 GA
| Optional. JBoss 5.1.0 GA Application Server is part of the installation process but you can choose to not install it using your already existing installtion. Please note that different versions are not supported and the installer will exit.
|-
|}

'''GreenVulcano Universal Installer'''

{{GVESB}} is based on GreenVulcano Universal Installer 1.0.0 which supports multiple GV_HOME installation on a system and will have a screen asking whether to use a new or an existing JBoss 5.1.0 GA installation. 
When installing {{GVESB}}, you should always use the same JBoss 5.1.0 GA installation simply choosing "Custom Installation" deselecting the "JBoss AS 5.1.0.GA" package and selecting your JBOSS_HOME when asked. 

'''Available Installation Options'''

Running the GreenVulcano Universal Installer the following options are available for certain platforms in both Console and GUI mode:

{| class="gvtable"
! Platform
! Options
! Purpose
|-
| Linux x86
| -java-home -console 
| JRE directory which point to desired bin/java executable. Run the installer in console mode.
|-
| Linux x86-64
| -java-home -console 
| JRE directory which point to desired bin/java executable. Run the installer in console mode.
|-
| Solaris (SPARC) (64-bit)
| -java-home -console 
| JRE directory which point to desired bin/java executable. Run the installer in console mode.
|-
| Solaris (x86-64)
| -java-home -console 
| JRE directory which point to desired bin/java executable. Run the installer in console mode.
|-
| IBM AIX (PPC64)
| -java-home -console 
| JRE directory which point to desired bin/java executable. Run the installer in console mode.
|-
| Microsoft Windows (all)
| no options
| The installer is available only in GUI mode without specifying any options.
|-
|}

'''Uninstalling GreenVulcano ESB'''

To uninstall your {{GVESB}} you can simply navigate through the Uninstaller directory located under your GV_HOME path and invoke: 
''java -jar GreenVulcano_Uninstaller.jar'' 

In case you have multiple GV_HOME on your system in the same INSTALL_PATH that sharing the same JBoss 5.1.0 GA installation please leave the ''"Force deletion of"'' checkbox unselected. 

Please note: The ''"Force deletion of"'' checkbox if selected will remove all the files and directories under your INSTALL_PATH.

GVExample TOUPPER A

2012-02-20T11:45:02Z

G.iannello: /* Description */

==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" destination-name="gvesb/jms/queue/TOUPPER_A_Request_Queue" name="JMSEnqueueTo::TOUPPER_A_Req" ref-dp="WriteString_JMSBytesMessageDataProvider" XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"
|-
| [[jms-enqueue]] || connection-factory="java:/XAConnectionFactory" delivery-mode="persistent" destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue" name="JMSEnqueueTo::TOUPPER_A_Resp" ref-dp="WriteString_JMSBytesMessageDataProvider" XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"
|-
| [[jms-dequeue]] || connection-factory="java:/XAConnectionFactory" delivery-mode="persistent" destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue" name="JMSDequeueTo::TOUPPER_A_Resp" ref-dp="ReadString_JMSBytesMessageDataProvider" receive-type="timeout" 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[]. The ''ReadString_JMSBytesMessageDataProvider'' extract the input JMS BytesMessage body as byte[] then convert it into a java.lang.String. 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" Field:
: direction="OUT" key="output" type="field">
: Expression: type="ognl"
:: writeBytes(#input.object.getBytes('UTF-8'))
|-
| [[Data provider|StringDataProvider]] || name="ReadString_JMSBytesMessageDataProvider" 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. 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 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_JMSDequeueTo::TOUPPER_A_Resp" 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" DequeueFilter:
: IDFilter
:: enabled="yes" use-input="yes"
|-
| GVNodeCheck || default-id="return_status" id="check_status" input="output_JMSEnqueueTo::TOUPPER_A_Req" on-exception-id="return_error" op-type="check" || default-id="return_status" id="check_status" input="output_JMSDequeueTo::TOUPPER_A_Resp" on-exception-id="return_error" op-type="check"
|-
| GVEndNode || id="return_status" op-type="end" output="output_JMSEnqueueTo::TOUPPER_A_Req" || id="return_status" op-type="end" output="output_JMSDequeueTo::TOUPPER_A_Resp"
|-
| GVEndNode || id="return_error" output="output_JMSEnqueueTo::TOUPPER_A_Req" || id="return_error" 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" input="input" next-node-id="enqueue_response" op-type="call" operation-name="toupper_call" output="output"
|-
| GVOperationNode || id="enqueue_response" id-system="GVESB" input="output" next-node-id="end" op-type="enqueue" operation-name="JMSEnqueueTo::TOUPPER_A_Resp" output="output"
|-
| GVEndNode || end-business-process="no" id="end" op-type="end" output="output" 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 A

2012-02-17T16:10:47Z

G.iannello: /* Description */

==Description==

This simple example shows how to configure an asynchronous service with Forward JMS.

==How To==

The best mode for creating a [[Service]] is through the Wizard. But for use it you must first define a new [[Group]], [[System]] and [[Channel]], if you do not want to use those already presents, and the workflow operations.

===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" destination-name="gvesb/jms/queue/TOUPPER_A_Request_Queue" name="JMSEnqueueTo::TOUPPER_A_Req" ref-dp="WriteString_JMSBytesMessageDataProvider" XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"
|-
| [[jms-enqueue]] || connection-factory="java:/XAConnectionFactory" delivery-mode="persistent" destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue" name="JMSEnqueueTo::TOUPPER_A_Resp" ref-dp="WriteString_JMSBytesMessageDataProvider" XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"
|-
| [[jms-dequeue]] || connection-factory="java:/XAConnectionFactory" delivery-mode="persistent" destination-name="gvesb/jms/queue/TOUPPER_A_Response_Queue" name="JMSDequeueTo::TOUPPER_A_Resp" ref-dp="ReadString_JMSBytesMessageDataProvider" receive-type="timeout" XAHelper
: auto-enlist="false"
: transaction-status="TMSUCCESS"
|-
| [[test-service-call]] || name="toupper_call"
|}

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" Field:
: direction="OUT" key="output" type="field">
: Expression: type="ognl"
:: writeBytes(#input.object.getBytes('UTF-8'))
|-
| [[Data provider|StringDataProvider]] || name="ReadString_JMSBytesMessageDataProvider" 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-asynchronous|asynchronous-asynchronous]]. 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. This service contains two Operations:
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 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_null" id="request" id-system="GVESB_TEST" input="input_null" next-node-id="check_status" op-type="dequeue" operation-name="JMSDequeueTo::TOUPPER_A_Resp"
|-
| GVNodeCheck || default-id="return_status" id="check_status" input="output_JMSEnqueueTo::TOUPPER_A_Req" on-exception-id="return_error" op-type="check" || default-id="return_status" id="check_status" input="output_null" 
on-exception-id="return_error" op-type="check"
|-
| GVEndNode || id="return_status" op-type="end" output="output_JMSEnqueueTo::TOUPPER_A_Req" || id="return_status" 
op-type="end" output="output_null"
|-
| GVEndNode || id="return_error" output="output_JMSEnqueueTo::TOUPPER_A_Req" || id="return_error" output="output_null"
|}

The GVCore.xml configuration file will be changed as follow:
* 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_null" next-node-id="check_status"
op-type="dequeue"
operation-name="JMSDequeueTo::TOUPPER_A_Resp"
output="output_null" 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_null" 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_null"
point-x="350" point-y="300" type="flow-node"/>
</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 arrived 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 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 voice select TOUPPER_A
# Into the System voice select GVESB_TEST
# Click Request

When test finishes, 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.). Standard fields and the detailed GVBuffer are described in the [[Testing#Data_input|Output File Name]] (we setted it as <nowiki>${{gv.app.home}}</nowiki>/log/TestOutput.txt).

In case of error or exceptions you can review the logs file presents in the folder <nowiki>${{gv.app.home}}</nowiki>/log/.

Shell-call

2012-02-17T14:27:39Z

G.iannello: /* Definition */

==Definition==
Many IT applications, within their business process, need to invoke shell commands. ''Gvvcl-shell'' plug-in can be used to invoke a command shell.
It is very simple to configure.

{{GVESB}} provides two different tools, {{L_GVCONSOLE}} and {{L_VULCON}}, to configure all supported plug-ins in {{GVESB}} services.

=={{VULCON}} / {{GVCONSOLE}} Configuration==
''shell-call'' is the operation that must be configured into {{L_VULCON}} or {{L_GVCONSOLE}} [[System section]] to invoke command shell.

In order to add an operation ''shell-call'' you must define the following fields:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || fixed || This attribute must assume the value '''call'''.
|-
| class || fixed || This attribute must assume the value '''it.greenvulcano.gvesb.virtual.shell.ShellCallOperation''' (java class that manages the ''shell-call'' invocation).
|-
| name || required || This field identify the operation name that you will use in service definition.
|-
| directory || optional ||Pathname of the directory in which the command is executed. This pathname can be static or may contain [[placeholders]] that are replaced at runtime. If this attribute is not present, the command is executed within the current working directory.
|-
| encoding || optional || The encoding with which encodes the command output in the [[GVBuffer]] body. If not specified, is used the ''file.encoding'' system property value.
|}

The following example shows the configuration generated from {{L_VULCON}} or {{L_GVCONSOLE}} when you configure a ''shell-call'' operation:

<syntaxhighlight lang="XML"><?xml version="1.0" encoding="UTF-8"?>
<Channel id-channel="CHANNEL-NAME">
<shell-call class="it.greenvulcano.gvesb.virtual.shell.ShellCallOperation"
directory="/home/greenvulcano/script" name="cat_file"
type="call">
<cmd>cat greenvulcano.log</cmd>
</shell-call>
</Channel>
</syntaxhighlight>

To use an ''excelreader-call'' in a {{GVESB}} service, you need to define a node of type [[GVOperationNode]] in [[Service section]] and define in the field ''operation-name'' the name defined in ''excelreader-call'' operation.

The following example shows the configuration generated from {{L_VULCON}} or {{L_GVCONSOLE}} when you configure an ''shell-call'' operation in {{GVESB}} service:

<syntaxhighlight lang="XML"><?xml version="1.0" encoding="UTF-8"?>
<GVServices name="SERVICES" type="module">
<Groups>
<Group group-activation="on" id-group="DEFAULT_GRP"/>
</Groups>
<Services>
<Service group-name="DEFAULT_GRP" id-service="SERVICE-NAME"
service-activation="on">
<Client id-system="SYSTEM-NAME" statistics="off" system-activation="on">
<Operation name="RequestReply" operation-activation="on"
out-check-type="none" type="operation">
<Participant id-channel="CHANNEL-NAME" id-system="SYSTEM-NAME"/>
<Flow first-node="cat_log_file" point-x="20" point-y="112">
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
id="shell-call" id-system="YOUR_SYSTEM"
input="input" next-node-id="end"
op-type="call"
operation-name="cat_file"
output="output" point-x="158"
point-y="112" type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
end-business-process="yes" id="end" op-type="end"
output="output" point-x="358" point-y="112"
type="flow-node"/>
</Flow>
</Operation>
</Client>
</Service>
</Services>
</GVServices>
</syntaxhighlight>

At this point you have configured a service with a ''shell-call'' operation.

GVExample TOUPPER

2012-02-17T11:50:44Z

G.iannello: /* How To */

==Description==

This simple example shows a [[Paradigms_of_communication|synchronous service]] and its configuration.
A string is passed and {{GVESB}} returns it 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 {{VULCON}} 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 the Location as <nowiki>${{gv.app.home}}/TEST/TESTFS</nowiki>. Then click finish. The new {{VULCON}} project GVEXAMPLE has been created.

The best mode for creating a [[Service]] is through the Service Wizard. Before using it you must first define a new [[Group]], [[System]] and [[Channel]], if you do not want to use those already present, and the workflow operations.
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''.

[[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 ''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 compressed file.

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

It is finally arrived 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 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 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 voice select TOUPPER
# Into the System voice select GVESB_TEST
# Click RequestReply

When test finishes, 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.). Standard fields and the detailed GVBuffer are described in the [[Testing#Data_input|Output File Name]] (we setted it as <nowiki>${{gv.app.home}}</nowiki>/log/TestOutput.txt).

In case of error or exceptions you can review the logs file present in the folder <nowiki>${{gv.app.home}}</nowiki>/log/.

GVExample TOUPPER

2012-02-17T11:47:06Z

G.iannello: /* Description */

==Description==

This simple example shows a [[Paradigms_of_communication|synchronous service]] and its configuration.
A string is passed and {{GVESB}} returns it uppercase.

==How To==

[[File:NewVulconProject.jpg|thumb| New Vulcon Project]]As this is our first example, the first step will be the creation of a new {{VULCON}} Project.
# From the Menu panel of {{VULCON}} 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 the Location as <nowiki>${{gv.app.home}}/TEST/TESTFS</nowiki>. Then click finish. The new {{VULCON}} project GVEXAMPLE has been created.

The best mode for creating a [[Service]] is through the Wizard. But for use it you must first define a new [[Group]], [[System]] and [[Channel]], if you do not want to use those already presents, and the workflow operations.
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''.

[[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, and your Group, we used TEST_GROUP. You can also select the paradigm, for this example will be [[Paradigms_of_communication#synchronous-synchronous|synchronous-synchronous]]. Click next.
# Set System as GVESB_TEST and Channel as TEST_CHANNEL. Then chose 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 open 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 follow:
* 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 compressed file.

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

It is finally arrived 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 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 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 voice select TOUPPER
# Into the System voice select GVESB_TEST
# Click RequestReply

When test finishes, 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.). Standard fields and the detailed GVBuffer are described in the [[Testing#Data_input|Output File Name]] (we setted it as <nowiki>${{gv.app.home}}</nowiki>/log/TestOutput.txt).

In case of error or exceptions you can review the logs file presents in the folder <nowiki>${{gv.app.home}}</nowiki>/log/.

Compatible platforms

2012-02-17T08:56:23Z

G.iannello: /* Supported Hardware Platforms */

==Supported Hardware Platforms==

{{GVESB}} can be installed on the following hardware platforms:

{| class="gvtable"
! Component !! Technology !! Note
|-
| valign="top"|Processor || Intel x86 x86-64 (AMD64 (AMD) or Intel64 (Intel) Intel IA-64 (Itanium, Itanium II) 1 CPU with frequency 1.8 Ghz || valign="top"|{{GVESB}} supports all processors based on Intel x86 and x86-64. Processors using different technologies are compatible to its support by the ''Java Virtual Machine''
|-
| valign="top"|Memory || 1Gb minim 2Gb recommended||
|-
| Disk space || 300Mb min || Depends on the log retention policies
|}

==Supported Software Platforms==

{{GVESB}} can be installed on different operating systems. The following table shows the list of compatible software platforms:

{| class="gvtable"
! Technology !! Platform
|-
| valign="top"|Operating system || Microsoft: Windows XP SP3, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008 
.nix: Linux (kernel 2.6.x), Solaris, AIX, HP-UX 
|-
| valign="top"|Application servers || JBoss v. 5.1.0-GA, any J2EE compliant application server 

|-
| Java || JDK 1.6 (Sun Microsystems)
|}

Compatible platforms

2012-02-17T08:55:30Z

G.iannello: /* Supported Software Platforms */

==Supported Hardware Platforms==

{{GVESB}} can be installed on the following hardware platforms:

{| class="gvtable"
! Component !! Technology !! Note
|-
| valign="top"|Processor || Intel x86 x86-64 (AMD64 (AMD) or Intel64 (Intel) Intel IA-64 (Itanium, Itanium II) 1 CPU with frequency 1.8 Ghz || valign="top"|{{GVESB}} supports all processors based on Intel x86 and x86-64. Processors using different technologies are compatible to its support by the ''Java Virtual Machine''
|-
| valign="top"|Memory || 1Gb minim 2Gb advised ||
|-
| Disk space || 300Mb min || Depends on the log retention policies
|}

==Supported Software Platforms==

{{GVESB}} can be installed on different operating systems. The following table shows the list of compatible software platforms:

{| class="gvtable"
! Technology !! Platform
|-
| valign="top"|Operating system || Microsoft: Windows XP SP3, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008 
.nix: Linux (kernel 2.6.x), Solaris, AIX, HP-UX 
|-
| valign="top"|Application servers || JBoss v. 5.1.0-GA, any J2EE compliant application server 

|-
| Java || JDK 1.6 (Sun Microsystems)
|}

Roadmap

2012-02-16T11:38:41Z

G.iannello: /* RoadMap */

===Road Map===

The engagement of GreenVulcano is to evolve the integration platform basing on the following criteria:

* Requests / Contributions from the community
* Specific needs of customers and developers
* Contributions of the partners / System Integrators

Our team adds its experience and expertise by offering innovative solutions in line with the vision that has always pushed us since our birth: simplicity and robustness.

GreenVulcano remains thus attached to the "real world", not in any way feeling the need to pursue or chasing at all costs the latest fashion trends of other products in the market.

The Roadmap is updated by our software architects and checked every six months.

===Version 3.2 (Q1 2012)===

1) “Sub Flow” management

2) BPEL Flows management

3) Every-component-Wizard on [[VulCon]] designer

4) Grafical Data Mapper

5) Drools integration

6) HL7 Adapter

7) New Wiki

===Version 3.3 (Q3 2012)===

1) Parallel flows

2) Grafical Try/Catch

3) Deploy and test from VulCon

===Version 3.4 (Q2 2013)===

1) Grafical Debugger

2) Service High availability and GV cluster management implementation

3) EJB 3.0 and Spring based version release

Template:Main Page/Overview

2012-02-16T11:38:27Z

G.iannello:

<div class="mainbox">
<h2>Overview</h2>
<div class="mainbox_content">
{{GVESB}} is an Enterprise Service Bus, [http://en.wikipedia.org/wiki/Open_source Open Source], fully developed by one of the most experienced [http://en.wikipedia.org/wiki/Enterprise_application_integration EAI] teams, derived from a deep understanding of the topic on vendor products and from the direct participation in implementations of ESB systems with very challenging design requirements:

* High transactions volume
* Large number of interconnected systems and different protocols supported
* Response in near real time
* Availability of technology adapters (Database, File, {{L_GVWS}}, e-Mail, etc)
* Availability of application adapters
* Powerful and flexible [[Data transformation]] engine

{{GVESB}} is a Java-based software built to support complex [http://en.wikipedia.org/wiki/Service-oriented_architecture SOA] architectures. Its [[multi-layer architecture]] allows an unlimited customization, solving most of enterprise integration issues like exchanging data between existing systems. Many [[plugins]] and [[adapters]] are already available for a huge flexibility.

Take a look at our [[Roadmap|Road Map]] and share your opinion with our team!

See also: [[License]]
</div>
</div>

GVExample ValidateRemoteXMLFiles

2012-02-16T10:05:52Z

G.iannello: /* Description */

==Description==

[[File:GVExamplesValidateXMLFilesShow.jpg|thumb|Validation of Remote XML Files]]
The flow is designed to show how {{GVESB}} manages the files present in a Remote file system and how can perform a validation of an xml file. It is executed following these steps:

* Reading XML files from a remote input directory via FTP (TextXML/input)
* Validating the read files using a predefined schema
* Coping valid and invalid files in two separated directories (TextXML/validated and TextXML/discarded)
* Saving a file <filename>.result with the <filename> validation error message

For this example the following parameters have been used:
* Server FTP
: FTP : localhost:3021
: Utente : test_user/test_user

=={{VULCON}} Configuration==

The implementation is the same of services [[GVExample ValidateXMLFiles |ValidateXMLFiles and ValidateSingleXMLFile]]. It consists of two services that perform the following tasks:
* ValidateRemoteXMLFiles: Enumerates the files to be validated
* ValidateSingleRemoteXMLFile: Validates and moves each single file

The difference between these services is in the operations to be performed. The following table shows the operations used for each service, divided by scope:
{|class="gvtable"
! Scope !! ValidateXMLFiles/ValidateSingleXMLFile !! ValidateRemoteXMLFiles/ValidateSingleRemoteXMLFile
|-
| Scanning XML files || [[fsmonitor-call]] || [[fsmonitor-call]]
|-
| Reading/download a file || [[filereader-call]] || [[remotemanager-call]]
|-
| Moving a file || [[filemanager-call]] || [[remotemanager-call]]
|-
| Writing/upload a file || [[filewriter-call]] || [[remotemanager-call]]
|}

To configure this service, the steps are as follows:
# Definition of systems, Channels and Operations
# Definition of Services
# Flow implementation

===Definition of Systems, Channels and Operations===

For the definition of the system go to the {{VULCON}} core view and insert the System GVESB (if not present).
Define the Channel TEST_CHANNEL_REMOTE_FILE with the following operations:
* [[fsmonitor-call]]: This operation allows to analyse the directory "path" and return an XML report with the list of files that verify the regular expression "file-mask" ("*. \ xml") in the given directory. Set its attributes as:
{|class="gvtable"
! Attribute !! Value
|-
| name || ScanXMLFiles
|-
| RemoteFileSystemMonitor/path || /home/test_user/TestXML/input
|-
| FileFilter/file-mask || .*\.xml
|-
| FileFilter/file-type || files-only
|-
| ResultFilter/existing || true
|-
| InMemoryMonitorStatus || dumpStatus="false"
|-
| FTPManager || autoConnect="false" hostType="UNIX" hostname="localhost" password="{3DES}pl1YKFjWlqMfdTIbxY17Mg==" port="3021" type="remote-manager" username="test_user"
|}
: This operation also imposes some properties into the output [[GVBuffer]], if files with the indicated conditions exist:
:* GVFSM_REPORT_CREATED setted to "true"
:* GVFSM_EXISTING_FILES number of file presents

* [[remotemanager-call]]: This operation allows to move the file, which name is present into the [[GVBuffer]] property "FILE_NAME" from the directory "input" to the directory which name is present into the [[GVBuffer]] property "TARGET". The directory of destination depends on the property "TARGET" value that worflow gives when imposes it to "validated" if the XML file is correct, or "discarded" if don't. Set its attributes as:
{|class="gvtable"
! Attribute !! Value
|-
| name || MoveFile
|-
| FTPManager || autoConnect="false" hostType="UNIX" hostname="localhost" password="{3DES}pl1YKFjWlqMfdTIbxY17Mg==" port="3021" type="remote-manager" username="test_user"
|-
| RemoteCommands/RemoteMoveCommand || isCritical="true" newName="ognl{{property['TARGET']}}/ognl{{property['FILE_NAME']}}" oldName="input/ognl{{property['FILE_NAME']}}" targetPath="/home/test_user/TestXML"
|}

* [[remotemanager-call]]: This operation allows to download the file which name is defined in the property "FILE_NAME" into the "remotePath" directory. The file content will be charged in GVBuffer.object field as array of bytes. Set its attributes as:
{|class="gvtable"
! Attribute !! Value
|-
| name || ReadFile
|-
| FTPManager || autoConnect="false" hostType="UNIX" hostname="localhost" password="{3DES}pl1YKFjWlqMfdTIbxY17Mg==" port="3021" type="remote-manager" username="test_user"
|-
| RemoteCommands/RemoteDownloadCommand || isCritical="true" remoteFilePattern="ognl{{property['FILE_NAME']}}" remotePath="/home/test_user/TestXML/input" toGVBufferExpression="setObject(new java.lang.String(#input))"
|}

* [[remotemanager-call]]: This operation allows to upload the file which name is defined concatenating the property "FILE_NAME" with the string ".result", into the "remotePath" directory. The file content will be present into the "fromGVBufferExpression" field. Set its attributes as:
{|class="gvtable"
! Attribute !! Value
|-
| name || WriteStatusFile
|-
| FTPManager || autoConnect="false" hostType="UNIX" hostname="localhost" password="{3DES}pl1YKFjWlqMfdTIbxY17Mg==" port="3021" type="remote-manager" username="test_user"
|-
| RemoteCommands/RemoteUploadCommand || fromGVBufferExpression="getObject().getBytes()" isCritical="true" remotePath="/home/test_user/TestXML/discarded" sourceFilePattern="ognl{{property['FILE_NAME']}}.result"
|}

===Definition of Services===

To define a Service for reading the files present into a directory, use the voice "Wizard new Service" (right clicking the Services element) with the following parameters:
{|class="gvtable"
! Attribute !! value
|-
| Service name || ValidateXMLFiles
|-
| Scenario || Synchronous- Synchronous
|-
| Client || GVESB
|-
| Server (Participant) || system = "GVESB" channel = "TEST_CHANNEL_FILE" request operation = "ScanXMLFiles"
|}

The Wizard will create a flow which has to be modified successively.

Analogously, use the "Wizard New Service" for creating the service for the validation of each single XML file present in the input directory, using the following parameters:
{|class="gvtable"
! Attribute !! value
|-
| Service name || ValidateSingleXMLFile
|-
| Scenario || Synchronous-Synchronous
|-
| Client || GVESB
|-
| Server (Participant) || system = "GVESB" channel = "TEST_CHANNEL_FILE" request operation = "ReadFile"
|}

The Wizard will create a flow that must be modified successively.

====Flow implementation====

[[File:GVExamplesValidateXMLFiles.jpg|thumb|ValidateRemoteXMLFile Configuration]]To define the flow for the service ''ValidateXMLFiles'', design it as it is shown in the picture:

In this first flow all files present into the directory "dir_scanner" are read, and for each one, the service ''ValidateSingleXMLFile'' will be invoked validating it.

The following table shows the parameters to be defined for each flow operation:
{|class="gvtable"
! Attribute !! value
|-
| Conditions/GVBufferCondition || condition="CheckNumFiles" Property:
: name="GVFSM-EXISTING_FILES"
: operator="greater"
: type="gvbuffer-field"
: value="0"
|-
| GVOperationNode || id="dir_scanner" id-system="GVESB" input="input" next-node-id="check_files" op-type="call" operation-name="ScanXMLFiles" output="files"
|-
| GVNodeCheck || default-id="end_nofile" id="check_files" input="files" on-exception-id="end_notok" op-type="check"
|-
| GVNodeCheck/GVRouting || condition="CheckNumFiles" next-node-id="iterate_file_list
|-
| GVIteratorOperationNode || id="iterate_file_list" collection-dp="fileNamesCollectionDP" input="files" next-node-id="end_ok" op-type="call" output="single-file"
|-
| GVIteratorOperationNode/CoreCall || change-log-context="true" id-service="ValidateSingleXMLFile" id-system="GVESB" operation="Request
|-
| GVEndNode || id="end_ok" op-type="end" output="files"
|-
| GVEndNode || id="end_notok" op-type="end" output="files"
|}

[[File:GVExamplesValidateSingleXMLFile.jpg|thumb| ValidateSingleRemoteXMLFile Configuration]]To define the flow for ValidateSingleXMLFile Service, design the flow as it is seen from the picture:

In this flow the file in input is read, validated using a specific XSD and, depending on the result, the file will be moved in other directory or a new file will be created with the result of the failed validation.

The workflow will be invoked passing into the GVBuffer.object of input an element "File" chosen from the generated XML report of the ScanXMLFiles operation.

The following table shows the parameters to be defined for each flow operation:
{|class="gvtable"
! Attribute !! value
|-
| first-node || fillProperties
|-
| ChangeGVBufferNode || id="fillProperties" 
input="node" 
next-node-id="read_validate_file" 
op-type="change GVBuffer" 
output="input"
|-
| ChangeGVBufferNode/ChangeGVBuffer || OGNLScript: property['FILE_NAME']=@it.greenvulcano.configuration.XMLConfig@get(object,'@name')
|-
| GVOperationNode || id="read_validate_file" 
id-system="GVESB" 
input="input" 
next-node-id="check_validate" 
op-type="call" 
operation-name="ReadFile"
|-
| GVOperationNode/OutputServices || xml-validation-service:
: critical="yes"
: internal="yes"
: remove-fields="yes"
xml-validation-call:
: default-xsd="ValidateXML.xsd"
: name="ValidateXML"
: return-dom="false"
: xsd-policy="force-default"
|-
| GVNodeCheck || default-id="validation_ok" 
id="check_validate" 
input="payload" 
on-exception-id="validation_failed"
|-
| ChangeGVBufferNode || id="validation_ok" 
input="input" 
next-node-id="move_file" 
clear-data="false"
|-
| ChangeGVBufferNode || id="validation_ok"
input="input"
next-node-id="move_file"
clear-data="false"
|-
| GVOperationNode || OGNLScript: property['TARGET'] = 'validated' 
id="move_file" 
id-system="GVESB" 
input="input" 
next-node-id="end" 
operation="MoveFile"
|-
| ChangeGVBufferNode || id="validation_failed"
input="input"
next-node-id="write_status"
clear-data="false"
|-
| GVOperationNode || OGNLScript: property['TARGET'] = 'discarded', setObject(' ' + #environment.get('payload')) 
id="write_status" 
id-system="GVESB" 
next-node-id="move_file" 
operation-name="WriteStatusFile" 
input="input"
|-
| GVEndNode || end-business-process="yes" 
id="end" 
op-type="end" 
output="input"
|}

TestFileAttachment

2012-02-16T09:52:34Z

G.iannello: /* Flow implementation */

==Description==

[[File:GVExamplesTestFileAttachment.jpg|thumb|TestFileAttachment description]]This example shows how to use {{GVESB}} to send an email containing attachments.

TestFileAttachment service executes the following operations:

* Reads a file from an input directory (TestAttach/input)
* Sends an email with this file as attachment
* Moves the sent file to another directory (TestAttach/sent)

=={{VULCON}} Configuration==

To configure TestFileAttachment service follow these steps:
# Define the [[System]], [[Channel]] and [[Operation|Operations]] required
# Define the [[Service|Services]]
# Implement the [[Flow|flows]].

===Defining System, Channel and Operations===

To define a System, go to {{VULCON}} core view and, into Systems element, insert the System GVESB if it is not already present.
From there create the Channel TEST_CHANNEL_FILE in which the following operations will be configured:

* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || ScanAttachments
FileCommands:
: [[Filemanager-call#FileSearchCommand|FileSearchCommand]]
:: filePattern=".*"
:: returnFullPath="true"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
|}
* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || MoveAttachments
FileCommands:
: [[Filemanager-call#FileMoveCommand|FileMoveCommand]]:
:: filePattern=".*"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
:: targetPath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent"
|}
* [[smtp-call]]
{|class="gvtable"
! Attribute !! Value
|-
| jndi-name || gvesb.mailServer
|-
| name || SendEmail
|-
| mail-message || content-type="text-html" high-priority="true" sender-display-name="GV ESB" subject="Test send attachments"
: destinations:
:: to:
::: mail-address: address="gv2@gv.com"
: message-body: gvBuffer-dump="false"
:: message-text: ${'Attachment file list:\n'+property['GV_SMTP_ATTACHMENTS']}
|}

===Flow implementation===

[[File:GVExamplesTestFileAttachmentFlow.jpg|thumb|TestFileAttachment flow]]To implement the TestFileAttachment service [[Flow]] design it as shown in the picture:

The service looks for the file presence in a directory, sends it as attachment and moves it into another directory.

The following table shows the nodes and attributes to be defined:

{|class="gvtable"
! Attribute/Subelement !! Value
|-
| first-node || Prepare
|-
| Conditions/GVBufferCondition || condition="FilesFound" type="condition"
Property:
: name="GVFM_FOUND_FILES_NUM"
: operator="greater"
: type="gvbuffer-field"
: value="0"
: value-type="integer"
|-
| GVOperationNode || dump-in-out="false" id="list_files" id-system="GVESB" input="input" next-node-id="check_files" op-type="call" operation-name="ScanAttachments" output="files"
|-
| GVNodeCheck || default-id="end-nofiles" id="check_files" input="files" on-exception-id="end" GVRouting:
: condition="FilesFound"
: next-node-id="prepare"
|-
| ChangeGVBufferNode || dump-in-out="true" id="prepare" input="files" next-node-id="send_email" output="files"
ChangeGVBuffer: clear-data="false"
: OGNLScript: property['GV_SMTP_ATTACHMENTS'] = property['GVFM_FOUND_FILES_LIST']
|-
| GVOperationNode || dump-in-out="false" id="send_email" id-system="GVESB" input="files" next-node-id="move_files" operation-name="SendEmail" output="files"
|-
| GVOperationNode || dump-in-out="false" id="move_files" id-system="GVESB" input="files" next-node-id="end" operation-name="MoveAttachments" output="files"
|-
| GVEndNode || end-business-process="yes" id="end-nofiles" output="files"
|-
| GVEndNode || end-business-process="yes" id="end" output="files"
|}

Save the editor clicking on the Save icon of Eclipse. Control that there are not errors in the flow and save it in the apposite icon present in the Core View of {{L_VULCON}}. From the Project view, expand your project, refresh (f5), and right clicking the folder "conf" export your new configuration.

=={{GVCONSOLE}} Configuration==

It is time to deploy and test your new Service. To do that execute the following steps:

[[File:GVCONSOLEDeploy.jpg|thumb|Deploy new Service]]Suppose you have saved the {{VULCON}} Configuration file 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 TestFileAttachment 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 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 services:
# Into the Service voice select TestFileAttachment
# Into the System voice select GVESB
# Click RequestReply

The Testing View will be expanded and it is also possible to view the GVBuffer Output panel where there are present some properties, among these the GVFM_FOUND_FILES_NUM property set to 3, representing the number of files found.

The file TestOutput.txt will be generated in the directory <nowiki>${{gv.app.home}}</nowiki>/log as previously set (see [[Testing]], [[data input]] area) containing information about the files found and the email already sent.
<syntaxhighlight lang="XML">
<pre>
----------- TEST N. 0 2012.02.15 at 18:02:32 -----------
Standard Field:
system = GVESB
service = EmailFileAttachment
id = 7F0001014F3BE51400059DBA
retCode = 0
GVBuffer: class java.lang.String

Properties:
messageID = <9388830.11329325352084.JavaMail.gv1@gv.com>
GVFM_FOUND_FILES_LIST = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
GVFM_FOUND_FILES_NUM = 3
GV_SMTP_ATTACHMENTS = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
</pre>
</syntaxhighlight>

Set a new account with the properties: 
Server SMTP/POP3
* SMTP : localhost:3025
* POP3: localhost:3110
* Server mailbox: gv1@gv.com (gv1/gv1)
* Client mailbox: gv2@gv.com (gv2/gv2) gv3@gv.com (gv3/gv3)

[[File:GVExamplesTestFileAttachmentEmail.jpg|thumb|TestFileAttachment email]]You will receive an email as this shown in the picture.

You can also check that the files were moved into the directory <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent.

TestFileAttachment

2012-02-16T09:49:53Z

G.iannello: /* {{GVCONSOLE}} Configuration */

==Description==

[[File:GVExamplesTestFileAttachment.jpg|thumb|TestFileAttachment description]]This example shows how to use {{GVESB}} to send an email containing attachments.

TestFileAttachment service executes the following operations:

* Reads a file from an input directory (TestAttach/input)
* Sends an email with this file as attachment
* Moves the sent file to another directory (TestAttach/sent)

=={{VULCON}} Configuration==

To configure TestFileAttachment service follow these steps:
# Define the [[System]], [[Channel]] and [[Operation|Operations]] required
# Define the [[Service|Services]]
# Implement the [[Flow|flows]].

===Defining System, Channel and Operations===

To define a System, go to {{VULCON}} core view and, into Systems element, insert the System GVESB if it is not already present.
From there create the Channel TEST_CHANNEL_FILE in which the following operations will be configured:

* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || ScanAttachments
FileCommands:
: [[Filemanager-call#FileSearchCommand|FileSearchCommand]]
:: filePattern=".*"
:: returnFullPath="true"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
|}
* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || MoveAttachments
FileCommands:
: [[Filemanager-call#FileMoveCommand|FileMoveCommand]]:
:: filePattern=".*"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
:: targetPath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent"
|}
* [[smtp-call]]
{|class="gvtable"
! Attribute !! Value
|-
| jndi-name || gvesb.mailServer
|-
| name || SendEmail
|-
| mail-message || content-type="text-html" high-priority="true" sender-display-name="GV ESB" subject="Test send attachments"
: destinations:
:: to:
::: mail-address: address="gv2@gv.com"
: message-body: gvBuffer-dump="false"
:: message-text: ${'Attachment file list:\n'+property['GV_SMTP_ATTACHMENTS']}
|}

===Flow implementation===

[[File:GVExamplesTestFileAttachmentFlow.jpg|thumb|TestFileAttachment flow]]To implement the TestFileAttachment service [[Flow]] design it as shown in the picture:

The service searchs the files present in a directory, sends it as attachment and moves it into another directory.

The following table shows the nodes and attributes to be defined:

{|class="gvtable"
! Attribute/Subelement !! Value
|-
| first-node || Prepare
|-
| Conditions/GVBufferCondition || condition="FilesFound" type="condition"
Property:
: name="GVFM_FOUND_FILES_NUM"
: operator="greater"
: type="gvbuffer-field"
: value="0"
: value-type="integer"
|-
| GVOperationNode || dump-in-out="false" id="list_files" id-system="GVESB" input="input" next-node-id="check_files" op-type="call" operation-name="ScanAttachments" output="files"
|-
| GVNodeCheck || default-id="end-nofiles" id="check_files" input="files" on-exception-id="end" GVRouting:
: condition="FilesFound"
: next-node-id="prepare"
|-
| ChangeGVBufferNode || dump-in-out="true" id="prepare" input="files" next-node-id="send_email" output="files"
ChangeGVBuffer: clear-data="false"
: OGNLScript: property['GV_SMTP_ATTACHMENTS'] = property['GVFM_FOUND_FILES_LIST']
|-
| GVOperationNode || dump-in-out="false" id="send_email" id-system="GVESB" input="files" next-node-id="move_files" operation-name="SendEmail" output="files"
|-
| GVOperationNode || dump-in-out="false" id="move_files" id-system="GVESB" input="files" next-node-id="end" operation-name="MoveAttachments" output="files"
|-
| GVEndNode || end-business-process="yes" id="end-nofiles" output="files"
|-
| GVEndNode || end-business-process="yes" id="end" output="files"
|}

Save the editor clicking on the Save icon of Eclipse. Control that there are not errors in the flow and save it in the apposite icon present in the Core View of {{L_VULCON}}. From the Project view, expand your project, refresh (f5), and right clicking the folder "conf" export your new configuration.

=={{GVCONSOLE}} Configuration==

It is time to deploy and test your new Service. To do that execute the following steps:

[[File:GVCONSOLEDeploy.jpg|thumb|Deploy new Service]]Suppose you have saved the {{VULCON}} Configuration file 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 TestFileAttachment 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 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 services:
# Into the Service voice select TestFileAttachment
# Into the System voice select GVESB
# Click RequestReply

The Testing View will be expanded and it is also possible to view the GVBuffer Output panel where there are present some properties, among these the GVFM_FOUND_FILES_NUM property set to 3, representing the number of files found.

The file TestOutput.txt will be generated in the directory <nowiki>${{gv.app.home}}</nowiki>/log as previously set (see [[Testing]], [[data input]] area) containing information about the files found and the email already sent.
<syntaxhighlight lang="XML">
<pre>
----------- TEST N. 0 2012.02.15 at 18:02:32 -----------
Standard Field:
system = GVESB
service = EmailFileAttachment
id = 7F0001014F3BE51400059DBA
retCode = 0
GVBuffer: class java.lang.String

Properties:
messageID = <9388830.11329325352084.JavaMail.gv1@gv.com>
GVFM_FOUND_FILES_LIST = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
GVFM_FOUND_FILES_NUM = 3
GV_SMTP_ATTACHMENTS = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
</pre>
</syntaxhighlight>

Set a new account with the properties: 
Server SMTP/POP3
* SMTP : localhost:3025
* POP3: localhost:3110
* Server mailbox: gv1@gv.com (gv1/gv1)
* Client mailbox: gv2@gv.com (gv2/gv2) gv3@gv.com (gv3/gv3)

[[File:GVExamplesTestFileAttachmentEmail.jpg|thumb|TestFileAttachment email]]You will receive an email as this shown in the picture.

You can also check that the files were moved into the directory <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent.

TestFileAttachment

2012-02-16T09:45:07Z

G.iannello: /* Defining System, Channel and Operations */

==Description==

[[File:GVExamplesTestFileAttachment.jpg|thumb|TestFileAttachment description]]This example shows how to use {{GVESB}} to send an email containing attachments.

TestFileAttachment service executes the following operations:

* Reads a file from an input directory (TestAttach/input)
* Sends an email with this file as attachment
* Moves the sent file to another directory (TestAttach/sent)

=={{VULCON}} Configuration==

To configure TestFileAttachment service follow these steps:
# Define the [[System]], [[Channel]] and [[Operation|Operations]] required
# Define the [[Service|Services]]
# Implement the [[Flow|flows]].

===Defining System, Channel and Operations===

To define a System, go to {{VULCON}} core view and, into Systems element, insert the System GVESB if it is not already present.
From there create the Channel TEST_CHANNEL_FILE in which the following operations will be configured:

* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || ScanAttachments
FileCommands:
: [[Filemanager-call#FileSearchCommand|FileSearchCommand]]
:: filePattern=".*"
:: returnFullPath="true"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
|}
* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || MoveAttachments
FileCommands:
: [[Filemanager-call#FileMoveCommand|FileMoveCommand]]:
:: filePattern=".*"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
:: targetPath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent"
|}
* [[smtp-call]]
{|class="gvtable"
! Attribute !! Value
|-
| jndi-name || gvesb.mailServer
|-
| name || SendEmail
|-
| mail-message || content-type="text-html" high-priority="true" sender-display-name="GV ESB" subject="Test send attachments"
: destinations:
:: to:
::: mail-address: address="gv2@gv.com"
: message-body: gvBuffer-dump="false"
:: message-text: ${'Attachment file list:\n'+property['GV_SMTP_ATTACHMENTS']}
|}

===Flow implementation===

[[File:GVExamplesTestFileAttachmentFlow.jpg|thumb|TestFileAttachment flow]]To implement the TestFileAttachment service [[Flow]] design it as shown in the picture:

The service searchs the files present in a directory, sends it as attachment and moves it into another directory.

The following table shows the nodes and attributes to be defined:

{|class="gvtable"
! Attribute/Subelement !! Value
|-
| first-node || Prepare
|-
| Conditions/GVBufferCondition || condition="FilesFound" type="condition"
Property:
: name="GVFM_FOUND_FILES_NUM"
: operator="greater"
: type="gvbuffer-field"
: value="0"
: value-type="integer"
|-
| GVOperationNode || dump-in-out="false" id="list_files" id-system="GVESB" input="input" next-node-id="check_files" op-type="call" operation-name="ScanAttachments" output="files"
|-
| GVNodeCheck || default-id="end-nofiles" id="check_files" input="files" on-exception-id="end" GVRouting:
: condition="FilesFound"
: next-node-id="prepare"
|-
| ChangeGVBufferNode || dump-in-out="true" id="prepare" input="files" next-node-id="send_email" output="files"
ChangeGVBuffer: clear-data="false"
: OGNLScript: property['GV_SMTP_ATTACHMENTS'] = property['GVFM_FOUND_FILES_LIST']
|-
| GVOperationNode || dump-in-out="false" id="send_email" id-system="GVESB" input="files" next-node-id="move_files" operation-name="SendEmail" output="files"
|-
| GVOperationNode || dump-in-out="false" id="move_files" id-system="GVESB" input="files" next-node-id="end" operation-name="MoveAttachments" output="files"
|-
| GVEndNode || end-business-process="yes" id="end-nofiles" output="files"
|-
| GVEndNode || end-business-process="yes" id="end" output="files"
|}

Save the editor clicking on the Save icon of Eclipse. Control that there are not errors in the flow and save it in the apposite icon present in the Core View of {{L_VULCON}}. From the Project view, expand your project, refresh (f5), and right clicking the folder "conf" export your new configuration.

=={{GVCONSOLE}} Configuration==

It is time to deploy and test your new Service. To do that execute the following steps:

[[File:GVCONSOLEDeploy.jpg|thumb|Deploy new Service]]Suppose you have saved the {{VULCON}} Configuration file 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 Sfoglia... (Browse) and select the file where you have 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 TestFileAttachment a new view will be open containing the files GVCore.xml present in local and in server.
# 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 services:
# Into the Service voice select TestFileAttachment
# Into the System voice select GVESB
# Click RequestReply

The Testing View will be expanded and it is also possible to view the GVBuffer Output panel where there are present some properties, among these the GVFM_FOUND_FILES_NUM property setted to 3, representing the number of files found.

The file TestOutput.txt will be generated in the directory <nowiki>${{gv.app.home}}</nowiki>/log as previously setted (see [[Testing]], [[data input]] area) containing information about the files found and the email already sent.
<syntaxhighlight lang="XML">
<pre>
----------- TEST N. 0 2012.02.15 at 18:02:32 -----------
Standard Field:
system = GVESB
service = EmailFileAttachment
id = 7F0001014F3BE51400059DBA
retCode = 0
GVBuffer: class java.lang.String

Properties:
messageID = <9388830.11329325352084.JavaMail.gv1@gv.com>
GVFM_FOUND_FILES_LIST = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
GVFM_FOUND_FILES_NUM = 3
GV_SMTP_ATTACHMENTS = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
</pre>
</syntaxhighlight>

Set a new account with the properties: 
Server SMTP/POP3
* SMTP : localhost:3025
* POP3: localhost:3110
* Server mailbox: gv1@gv.com (gv1/gv1)
* Client mailbox: gv2@gv.com (gv2/gv2) gv3@gv.com (gv3/gv3)

[[File:GVExamplesTestFileAttachmentEmail.jpg|thumb|TestFileAttachment email]]You will receive an email as this shown in the picture.

You can also check that the files where moved into the directory <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent.

TestFileAttachment

2012-02-16T09:43:41Z

G.iannello: /* Description */

==Description==

[[File:GVExamplesTestFileAttachment.jpg|thumb|TestFileAttachment description]]This example shows how to use {{GVESB}} to send an email containing attachments.

TestFileAttachment service executes the following operations:

* Reads a file from an input directory (TestAttach/input)
* Sends an email with this file as attachment
* Moves the sent file to another directory (TestAttach/sent)

=={{VULCON}} Configuration==

To configure TestFileAttachment service follow these steps:
# Define the [[System]], [[Channel]] and [[Operation|Operations]] required
# Define the [[Service|Services]]
# Implement the [[Flow|flows]].

===Defining System, Channel and Operations===

To define a System, go to {{VULCON}} core view and, into Systems element, insert the System GVESB if it is not already present. Inside of it create the Channel TEST_CHANNEL_FILE in which the following operations will be configured:

* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || ScanAttachments
FileCommands:
: [[Filemanager-call#FileSearchCommand|FileSearchCommand]]
:: filePattern=".*"
:: returnFullPath="true"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
|}
* [[filemanager-call]]
{|class="gvtable"
! Attribute/Subelement !! Value
|-
| name || MoveAttachments
FileCommands:
: [[Filemanager-call#FileMoveCommand|FileMoveCommand]]:
:: filePattern=".*"
:: sourcePath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input"
:: targetPath="<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent"
|}
* [[smtp-call]]
{|class="gvtable"
! Attribute !! Value
|-
| jndi-name || gvesb.mailServer
|-
| name || SendEmail
|-
| mail-message || content-type="text-html" high-priority="true" sender-display-name="GV ESB" subject="Test send attachments"
: destinations:
:: to:
::: mail-address: address="gv2@gv.com"
: message-body: gvBuffer-dump="false"
:: message-text: ${'Attachment file list:\n'+property['GV_SMTP_ATTACHMENTS']}
|}

===Flow implementation===

[[File:GVExamplesTestFileAttachmentFlow.jpg|thumb|TestFileAttachment flow]]To implement the TestFileAttachment service [[Flow]] design it as shown in the picture:

The service searchs the files present in a directory, sends it as attachment and moves it into another directory.

The following table shows the nodes and attributes to be defined:

{|class="gvtable"
! Attribute/Subelement !! Value
|-
| first-node || Prepare
|-
| Conditions/GVBufferCondition || condition="FilesFound" type="condition"
Property:
: name="GVFM_FOUND_FILES_NUM"
: operator="greater"
: type="gvbuffer-field"
: value="0"
: value-type="integer"
|-
| GVOperationNode || dump-in-out="false" id="list_files" id-system="GVESB" input="input" next-node-id="check_files" op-type="call" operation-name="ScanAttachments" output="files"
|-
| GVNodeCheck || default-id="end-nofiles" id="check_files" input="files" on-exception-id="end" GVRouting:
: condition="FilesFound"
: next-node-id="prepare"
|-
| ChangeGVBufferNode || dump-in-out="true" id="prepare" input="files" next-node-id="send_email" output="files"
ChangeGVBuffer: clear-data="false"
: OGNLScript: property['GV_SMTP_ATTACHMENTS'] = property['GVFM_FOUND_FILES_LIST']
|-
| GVOperationNode || dump-in-out="false" id="send_email" id-system="GVESB" input="files" next-node-id="move_files" operation-name="SendEmail" output="files"
|-
| GVOperationNode || dump-in-out="false" id="move_files" id-system="GVESB" input="files" next-node-id="end" operation-name="MoveAttachments" output="files"
|-
| GVEndNode || end-business-process="yes" id="end-nofiles" output="files"
|-
| GVEndNode || end-business-process="yes" id="end" output="files"
|}

Save the editor clicking on the Save icon of Eclipse. Control that there are not errors in the flow and save it in the apposite icon present in the Core View of {{L_VULCON}}. From the Project view, expand your project, refresh (f5), and right clicking the folder "conf" export your new configuration.

=={{GVCONSOLE}} Configuration==

It is time to deploy and test your new Service. To do that execute the following steps:

[[File:GVCONSOLEDeploy.jpg|thumb|Deploy new Service]]Suppose you have saved the {{VULCON}} Configuration file 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 Sfoglia... (Browse) and select the file where you have 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 TestFileAttachment a new view will be open containing the files GVCore.xml present in local and in server.
# 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 services:
# Into the Service voice select TestFileAttachment
# Into the System voice select GVESB
# Click RequestReply

The Testing View will be expanded and it is also possible to view the GVBuffer Output panel where there are present some properties, among these the GVFM_FOUND_FILES_NUM property setted to 3, representing the number of files found.

The file TestOutput.txt will be generated in the directory <nowiki>${{gv.app.home}}</nowiki>/log as previously setted (see [[Testing]], [[data input]] area) containing information about the files found and the email already sent.
<syntaxhighlight lang="XML">
<pre>
----------- TEST N. 0 2012.02.15 at 18:02:32 -----------
Standard Field:
system = GVESB
service = EmailFileAttachment
id = 7F0001014F3BE51400059DBA
retCode = 0
GVBuffer: class java.lang.String

Properties:
messageID = <9388830.11329325352084.JavaMail.gv1@gv.com>
GVFM_FOUND_FILES_LIST = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
GVFM_FOUND_FILES_NUM = 3
GV_SMTP_ATTACHMENTS = <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/001.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/002.txt;
<nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/input/003.txt
</pre>
</syntaxhighlight>

Set a new account with the properties: 
Server SMTP/POP3
* SMTP : localhost:3025
* POP3: localhost:3110
* Server mailbox: gv1@gv.com (gv1/gv1)
* Client mailbox: gv2@gv.com (gv2/gv2) gv3@gv.com (gv3/gv3)

[[File:GVExamplesTestFileAttachmentEmail.jpg|thumb|TestFileAttachment email]]You will receive an email as this shown in the picture.

You can also check that the files where moved into the directory <nowiki>${{gv.app.home}}</nowiki>/TEST/TESTFS/TestAttach/sent.

Service

2012-02-13T15:54:23Z

G.iannello: /* {{VULCON}} / {{GVESB}} Configuration */

==Description==

A [http://en.wikipedia.org/wiki/Service_(systems_architecture) Service] is the provisioning of one or more functions ([[Operation|Operations]]) within a [[System]] environment. It refers to a group of software components that perform a specific business logic.

=={{VULCON}} / {{GVESB}} Configuration==

A {{GVESB}}'s service is identified by a unique name (id-service), belongs to a [[group]] and has an activation state and a number of clients enabled at its invocation (section [[Client]]).

You can configure the conditions applied to the routing of Service's flows ([[Conditions]] section).

The definitions used here are valid for all [[Flow|flows]] associated with service and overwrite any global definitions.

[[File:VULCONService.jpg|thumb|Service configuration]]The Service element has the attributes:
* ''id-service'': The unique name of the service. Corresponds to the value contained in the 'service' field of the data buffer (GVBuffer).
* ''group-name'': Service group membership. Groups are defined in the [[Group]] section.
* ''service-activation'': Activation status of service. The status can be: - on: service is active. - paused: service is inactive, the asynchronous client's requests are taken in charge by {{GVESB}}. They will be served when the service return on state 'on'. - off: service is inactive and no request are taken in charge by {{GVESB}}. The current version doesn't implement the state 'paused'. The attribute's default value is: on.
* ''creation-date'': Service creation date. The information in this field is purely descriptive and has no impact on the functionality of {{GVESB}}. This information will be used for the production of reports on configuration.
* ''brief-description'': Service description. This information will be used for the production of reports on configuration.

and the subelements:
* Description,
* Operation,
* BpelOperation,
* AliasList,
* Conditions.

==How to==

You can insert a new ''Service'' from the Core view right clicking the [[Services]] element, Insert after (or Insert before), ''Service''.
It is also possible to create a new Service using the [[Wizard]].

The respective part of the ''GVCore.xml'' configuration file becomes:

<syntaxhighlight lang="XML">
<Service group-name="GVTEST" id-service="Test" service-activation="on" statistics="off">
<Operation name="RequestReply" operation-activation="on" out-check-type="sys-svc-id" type="operation">
<Participant id-channel="TEST_CHANNEL_FILE" id-system="GVESB"/>
<Flow first-node="call_Test" point-x="20" point-y="150">
---
</Flow>
</Operation>
</Service>
</syntaxhighlight>

Service

2012-02-13T15:53:44Z

G.iannello: /* {{VULCON}} / {{GVESB}} Configuration */

==Description==

A [http://en.wikipedia.org/wiki/Service_(systems_architecture) Service] is the provisioning of one or more functions ([[Operation|Operations]]) within a [[System]] environment. It refers to a group of software components that perform a specific business logic.

=={{VULCON}} / {{GVESB}} Configuration==

A {{GVESB}}'s service is identified by a unique name (id-service), belongs to a [[group]] and has an activation state and a number of clients enabled at its invocation (section [[Client]]).

You can configure the conditions applied to the routing of Service's flows ([[Conditions]] section).

The definitions used here are valid for all [[Flow|flows]] associated with service and overwrite any global definitions.

[[File:VULCONService.jpg|thumb|Service configuration]]The Service element has the attributes:
* ''id-service'': The unique name of the service. Corresponds to the value contained in the 'service' field of the data buffer (GVBuffer).
* ''group-name'': Service group membership. Groups are defined in the [[Group]] section.
* ''service-activation'': Activation status of service. The status can be: - on: service is active. - paused: service is inactive, the asynchronous client's requests are taken in charge by {{GVESB}}. They will be served when the service return on state 'on'. - off: service is inactive and no request are taken in charge by {{GVESB}}. The current version don't implement the state 'paused'. The attribute's default value is: on.
* ''creation-date'': Service creation date. The information in this field is purely descriptive and has no impact on the functionality of {{GVESB}}. This information will be used for the production of reports on configuration.
* ''brief-description'': Service description. This information will be used for the production of reports on configuration.

and the subelements:
* Description,
* Operation,
* BpelOperation,
* AliasList,
* Conditions.

==How to==

You can insert a new ''Service'' from the Core view right clicking the [[Services]] element, Insert after (or Insert before), ''Service''.
It is also possible to create a new Service using the [[Wizard]].

The respective part of the ''GVCore.xml'' configuration file becomes:

<syntaxhighlight lang="XML">
<Service group-name="GVTEST" id-service="Test" service-activation="on" statistics="off">
<Operation name="RequestReply" operation-activation="on" out-check-type="sys-svc-id" type="operation">
<Participant id-channel="TEST_CHANNEL_FILE" id-system="GVESB"/>
<Flow first-node="call_Test" point-x="20" point-y="150">
---
</Flow>
</Operation>
</Service>
</syntaxhighlight>

Service

2012-02-13T15:53:17Z

G.iannello: /* {{VULCON}} / {{GVESB}} Configuration */

==Description==

A [http://en.wikipedia.org/wiki/Service_(systems_architecture) Service] is the provisioning of one or more functions ([[Operation|Operations]]) within a [[System]] environment. It refers to a group of software components that perform a specific business logic.

=={{VULCON}} / {{GVESB}} Configuration==

A {{GVESB}}'s service is identified by a unique name (id-service), belongs to a [[group]] and has an activation state and a number of clients enabled at its invocation (section [[Client]]).

You can configure the conditions applied to the routing of Service's flows ([[Conditions]] section).

The definitions used here are valid for all [[Flow|flows]] associated with service and overwrite any global definitions.

[[File:VULCONService.jpg|thumb|Service configuration]]The Service element has the attributes:
* ''id-service'': The unique name of the service. Corresponds to the value contained in the 'service' field of the data buffer (GVBuffer).
* ''group-name'': Service group membership. Groups are defined in the [[Groups]] section.
* ''service-activation'': Activation status of service. The status can be: - on: service is active. - paused: service is inactive, the asynchronous client's requests are taken in charge by {{GVESB}}. They will be served when the service return on state 'on'. - off: service is inactive and no request are taken in charge by {{GVESB}}. The current version don't implement the state 'paused'. The attribute's default value is: on.
* ''creation-date'': Service creation date. The information in this field is purely descriptive and has no impact on the functionality of {{GVESB}}. This information will be used for the production of reports on configuration.
* ''brief-description'': Service description. This information will be used for the production of reports on configuration.

and the subelements:
* Description,
* Operation,
* BpelOperation,
* AliasList,
* Conditions.

==How to==

You can insert a new ''Service'' from the Core view right clicking the [[Services]] element, Insert after (or Insert before), ''Service''.
It is also possible to create a new Service using the [[Wizard]].

The respective part of the ''GVCore.xml'' configuration file becomes:

<syntaxhighlight lang="XML">
<Service group-name="GVTEST" id-service="Test" service-activation="on" statistics="off">
<Operation name="RequestReply" operation-activation="on" out-check-type="sys-svc-id" type="operation">
<Participant id-channel="TEST_CHANNEL_FILE" id-system="GVESB"/>
<Flow first-node="call_Test" point-x="20" point-y="150">
---
</Flow>
</Operation>
</Service>
</syntaxhighlight>

Service

2012-02-13T15:52:58Z

G.iannello: /* {{VULCON}} / {{GVESB}} Configuration */

==Description==

A [http://en.wikipedia.org/wiki/Service_(systems_architecture) Service] is the provisioning of one or more functions ([[Operation|Operations]]) within a [[System]] environment. It refers to a group of software components that perform a specific business logic.

=={{VULCON}} / {{GVESB}} Configuration==

A {{GVESB}}'s service is identified by a unique name (id-service), belongs to a [[group]] and has an activation state and a number of clients enabled at its invocation (section [[Clients]]).

You can configure the conditions applied to the routing of Service's flows ([[Conditions]] section).

The definitions used here are valid for all [[Flow|flows]] associated with service and overwrite any global definitions.

[[File:VULCONService.jpg|thumb|Service configuration]]The Service element has the attributes:
* ''id-service'': The unique name of the service. Corresponds to the value contained in the 'service' field of the data buffer (GVBuffer).
* ''group-name'': Service group membership. Groups are defined in the [[Groups]] section.
* ''service-activation'': Activation status of service. The status can be: - on: service is active. - paused: service is inactive, the asynchronous client's requests are taken in charge by {{GVESB}}. They will be served when the service return on state 'on'. - off: service is inactive and no request are taken in charge by {{GVESB}}. The current version don't implement the state 'paused'. The attribute's default value is: on.
* ''creation-date'': Service creation date. The information in this field is purely descriptive and has no impact on the functionality of {{GVESB}}. This information will be used for the production of reports on configuration.
* ''brief-description'': Service description. This information will be used for the production of reports on configuration.

and the subelements:
* Description,
* Operation,
* BpelOperation,
* AliasList,
* Conditions.

==How to==

You can insert a new ''Service'' from the Core view right clicking the [[Services]] element, Insert after (or Insert before), ''Service''.
It is also possible to create a new Service using the [[Wizard]].

The respective part of the ''GVCore.xml'' configuration file becomes:

<syntaxhighlight lang="XML">
<Service group-name="GVTEST" id-service="Test" service-activation="on" statistics="off">
<Operation name="RequestReply" operation-activation="on" out-check-type="sys-svc-id" type="operation">
<Participant id-channel="TEST_CHANNEL_FILE" id-system="GVESB"/>
<Flow first-node="call_Test" point-x="20" point-y="150">
---
</Flow>
</Operation>
</Service>
</syntaxhighlight>

Service

2012-02-13T15:52:15Z

G.iannello: /* Description */

==Description==

A [http://en.wikipedia.org/wiki/Service_(systems_architecture) Service] is the provisioning of one or more functions ([[Operation|Operations]]) within a [[System]] environment. It refers to a group of software components that perform a specific business logic.

=={{VULCON}} / {{GVESB}} Configuration==

A {{GVESB}}'s service is identified by a unique name (id-service), belongs to a group and has an activation state and a number of clients enabled at its invocation (section [[Clients]]).

You can configure the conditions applied to the routing of Service's flows ([[Conditions]] section).

The definitions used here are valid for all [[Flow|flows]] associated with service and overwrite any global definitions.

[[File:VULCONService.jpg|thumb|Service configuration]]The Service element has the attributes:
* ''id-service'': The unique name of the service. Corresponds to the value contained in the 'service' field of the data buffer (GVBuffer).
* ''group-name'': Service group membership. Groups are defined in the [[Groups]] section.
* ''service-activation'': Activation status of service. The status can be: - on: service is active. - paused: service is inactive, the asynchronous client's requests are taken in charge by {{GVESB}}. They will be served when the service return on state 'on'. - off: service is inactive and no request are taken in charge by {{GVESB}}. The current version don't implement the state 'paused'. The attribute's default value is: on.
* ''creation-date'': Service creation date. The information in this field is purely descriptive and has no impact on the functionality of {{GVESB}}. This information will be used for the production of reports on configuration.
* ''brief-description'': Service description. This information will be used for the production of reports on configuration.

and the subelements:
* Description,
* Operation,
* BpelOperation,
* AliasList,
* Conditions.

==How to==

You can insert a new ''Service'' from the Core view right clicking the [[Services]] element, Insert after (or Insert before), ''Service''.
It is also possible to create a new Service using the [[Wizard]].

The respective part of the ''GVCore.xml'' configuration file becomes:

<syntaxhighlight lang="XML">
<Service group-name="GVTEST" id-service="Test" service-activation="on" statistics="off">
<Operation name="RequestReply" operation-activation="on" out-check-type="sys-svc-id" type="operation">
<Participant id-channel="TEST_CHANNEL_FILE" id-system="GVESB"/>
<Flow first-node="call_Test" point-x="20" point-y="150">
---
</Flow>
</Operation>
</Service>
</syntaxhighlight>

System

2012-02-13T15:51:24Z

G.iannello: /* {{VULCON}} / {{GVESB}} Configuration */

==Description==

The '''System''' element is any system or application interconnected with {{GVESB}}.

=={{VULCON}} / {{GVESB}} Configuration==

A ''System'' is identified by an univocal name, has an activation state, and a number of communication interfaces grouped in [[channel|channels]].
Moreover, in order to simplify operational management, for each system you can define a list of contacts (see below).

Its attributes are:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| id-system || required || System unique identifier.
|-
| system-activation || optional || Activation status of system. The status can be:
* on: system services are active.
* paused: system services are inactive, the asynchronous client requests are taken in charge by {{GVESB}}. They will be served when the system returns on state 'on'.
* off: system services are inactive and no request is taken in charge by {{GVESB}}. The current version does not implement the state 'paused'. The attribute's default value is: on.
|}

and its subelements:
* Description
* [[Channel]]
* Contact (see bellow)

The configurations of all systems interfaced to {{GVESB}} are contained in the element '''Systems'''.

==Contact==

This element identifies a ''contact'' for an external system. The information contained in this element are optional and have no impact on the {{GVESB}} functioning.

Such information may be used to produce reports.

The Contact Element is used only by ''System''.

It has the following attributes:

* ''first-name''
* ''last-name''
* ''role''
* ''mobile''
* ''telephone''
* ''e-mail''

System

2012-02-13T15:48:02Z

G.iannello: /* Description */

==Description==

The '''System''' element is any system or application interconnected with {{GVESB}}.

=={{VULCON}} / {{GVESB}} Configuration==

A ''System'' is identified by a single name, has an activation state, and a number of communication interfaces grouped in channels.
In addition to operational information for each system you can define a list of contacts (see bellow).

Its attributes are:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| id-system || required || System unique identifier.
|-
| system-activation || optional || Activation status of system. The status can be:
* on: system's services are active.
* paused: system's services are inactive, the asynchronous client's requests are taken in charge by {{GVESB}}. They will be served when the system return on state 'on'.
* off: system's services are inactive and no request are tacken in charge by {{GVESB}}. The current version does not implement the state 'paused'. The attribute's default value is: on.
|}

and its subelements:
* Description
* [[Channel]]
* Contact (see bellow)

The configurations of all systems interfaced to {{GVESB}} are contained in the element '''Systems'''.

==Contact==

This element identifies a ''contact'' for an external system. The information contained in this element are optional and have no impact on the {{GVESB}} functioning.

Such information may be used to produce reports.

The Contact Element is used only by ''System''.

It has the following attributes:

* ''first-name''
* ''last-name''
* ''role''
* ''mobile''
* ''telephone''
* ''e-mail''

GetAnagrafica ws bottom-up method

2012-02-13T15:46:16Z

G.iannello: /* SERVICE SECTION */

== Definition ==

Let's start from a {{GVESB}} [[service]] "getAnagrafica" that simply returns the anagrafic data present in table ''Anagrafica''.

== SYSTEM SECTION ==
The first image shows how to create an operation system section.
In the tag system let's define a new Channel "CH_DB" and add a [[db-call]] operation, in [[db-call]] operation set the parameters for the Element DBOoperation, Statement and ResultSet:
*[[DBOperations]]-->[[DBOperations|DataSourceConnection]]
**jndi-name: insert the name of jndi DataSource in this example ds.anagrafica
*Statement
**StatementValue: in this field insert the following query "select cognome,nome,citta from anagrafica"
*[[ResultSet]]-->[[Formatter|QueryFormatter]]
**type: choose base_formatter
**structure: ONLY_DATA, remember if you don't want also metadata form query select for filed structure the value ONLY_DATA
{|
|-
| [[File:1buws.png|thumb|WebService Wizard first window]]
| [[File:2buws.png|thumb|WebService Wizard second window]]
| [[File:3buws.png|thumb|WebService Wizard third window]]
|}
The system section has been configured.

== SERVICE SECTION ==
This section shows the getAnagrafica service configuration.
To configure the [[service]] do the following steps:
#On the elements [[Service]] add a service with name "getAnagrafica".
#On the "request" node set db-call as operation
#As output-service set a xsl trasformation to transform the data as Web Service XSD expected.
To create a new trasformation go in section GvDataTrasformation and execute the following steps:
#On section Trasformation add new xsl trasformation
#On the opened page set:
##trasformation name:"getAnagrafica"
##Data source:Default
##xsd input: choose database.xsd
##root xsd input: RowSet (is the root element that return the query)
##xsd output: anagrafica.xsd (the schema that the Web Service expected)
##root XSD output: the root element of the xsd.
To create the xsl trasformation between the file Database.xsd and anagrafica.xsd you can use [[XML Data mapper]] tool
{|
|-
| [[File:4buws.png|thumb|right|WebService Wizard fourth window]]
| [[File:5buws.png|thumb|right|WebService Wizard five window]]
| [[File:6buws.png|thumb|right|Xml data mapper]]
|}

== Web Service wizard ==
On service element choose bottom-up development method, on the opened page set the following parameter:
*Web Service name: getAnagrafica
*Target namespace operation: http://www.greenvulcano.it/greenvulcano
*Operation to bind: choose getAnagrafica - RequestReply
*choose soap trasport as protocol
*set input type Web Service: body (this indicate that the input at getAnagrafica service is only the body of soap request)
*set data provider name: domWSDataProvider
If you are familiary with soapui framework you can test the web service, the image "WebService soapui test" show how to.
{|
|-
| [[File:7buws.png|thumb|right|WebService Wizard first window]]
| [[File:8buws.png|thumb|right|WebService Wizard second window]]
| [[File:9buws.png|thumb|right|WebService Wizard third window]]
| [[File:10buws.png|thumb|right|WebService soapui test]]
|}

GetAnagrafica ws bottom-up method

2012-02-13T15:45:25Z

G.iannello: /* SYSTEM SECTION */

== Definition ==

Let's start from a {{GVESB}} [[service]] "getAnagrafica" that simply returns the anagrafic data present in table ''Anagrafica''.

== SYSTEM SECTION ==
The first image shows how to create an operation system section.
In the tag system let's define a new Channel "CH_DB" and add a [[db-call]] operation, in [[db-call]] operation set the parameters for the Element DBOoperation, Statement and ResultSet:
*[[DBOperations]]-->[[DBOperations|DataSourceConnection]]
**jndi-name: insert the name of jndi DataSource in this example ds.anagrafica
*Statement
**StatementValue: in this field insert the following query "select cognome,nome,citta from anagrafica"
*[[ResultSet]]-->[[Formatter|QueryFormatter]]
**type: choose base_formatter
**structure: ONLY_DATA, remember if you don't want also metadata form query select for filed structure the value ONLY_DATA
{|
|-
| [[File:1buws.png|thumb|WebService Wizard first window]]
| [[File:2buws.png|thumb|WebService Wizard second window]]
| [[File:3buws.png|thumb|WebService Wizard third window]]
|}
The system section has been configured.

== SERVICE SECTION ==
This section shows the getAnagrafica service configuration.
To configure the service performs the following steps:
#On the elements [[Service]] add a service with name "getAnagrafica".
#On the "request" node set db-call as operation
#As output-service set a xsl trasformation to transform the data as Web Service XSD expected.
To create a new trasformation go in section GvDataTrasformation and execute the following steps:
#On section Trasformation add new xsl trasformation
#On the opened page set:
##trasformation name:"getAnagrafica"
##Data source:Default
##xsd input: choose database.xsd
##root xsd input: RowSet (is the root element that return the query)
##xsd output: anagrafica.xsd (the schema that the Web Service expected)
##root XSD output: the root element of the xsd.
To create the xsl trasformation between the file Database.xsd and anagrafica.xsd you can use [[XML Data mapper]] tool
{|
|-
| [[File:4buws.png|thumb|right|WebService Wizard fourth window]]
| [[File:5buws.png|thumb|right|WebService Wizard five window]]
| [[File:6buws.png|thumb|right|Xml data mapper]]
|}
== Web Service wizard ==
On service element choose bottom-up development method, on the opened page set the following parameter:
*Web Service name: getAnagrafica
*Target namespace operation: http://www.greenvulcano.it/greenvulcano
*Operation to bind: choose getAnagrafica - RequestReply
*choose soap trasport as protocol
*set input type Web Service: body (this indicate that the input at getAnagrafica service is only the body of soap request)
*set data provider name: domWSDataProvider
If you are familiary with soapui framework you can test the web service, the image "WebService soapui test" show how to.
{|
|-
| [[File:7buws.png|thumb|right|WebService Wizard first window]]
| [[File:8buws.png|thumb|right|WebService Wizard second window]]
| [[File:9buws.png|thumb|right|WebService Wizard third window]]
| [[File:10buws.png|thumb|right|WebService soapui test]]
|}

GetAnagrafica ws bottom-up method

2012-02-13T15:44:27Z

G.iannello: /* Definition */

== Definition ==

Let's start from a {{GVESB}} [[service]] "getAnagrafica" that simply returns the anagrafic data present in table ''Anagrafica''.

== SYSTEM SECTION ==
The first image shows how create an operation system section.
In the tag system define a new Channel "CH_DB" and add a [[db-call]] operation, in [[db-call]] operation set the parameters for the Element DBOoperation, Statement and ResultSet:
*[[DBOperations]]-->[[DBOperations|DataSourceConnection]]
**jndi-name: insert the name of jndi DataSource in this example ds.anagrafica
*Statement
**StatementValue: in this field insert the following query "select cognome,nome,citta from anagrafica"
*[[ResultSet]]-->[[Formatter|QueryFormatter]]
**type: choose base_formatter
**structure: ONLY_DATA, remember if you don't want also metadata form query select for filed structure the value ONLY_DATA
{|
|-
| [[File:1buws.png|thumb|WebService Wizard first window]]
| [[File:2buws.png|thumb|WebService Wizard second window]]
| [[File:3buws.png|thumb|WebService Wizard third window]]
|}
The system section has been configured

== SERVICE SECTION ==
This section shows the getAnagrafica service configuration.
To configure the service performs the following steps:
#On the elements [[Service]] add a service with name "getAnagrafica".
#On the "request" node set db-call as operation
#As output-service set a xsl trasformation to transform the data as Web Service XSD expected.
To create a new trasformation go in section GvDataTrasformation and execute the following steps:
#On section Trasformation add new xsl trasformation
#On the opened page set:
##trasformation name:"getAnagrafica"
##Data source:Default
##xsd input: choose database.xsd
##root xsd input: RowSet (is the root element that return the query)
##xsd output: anagrafica.xsd (the schema that the Web Service expected)
##root XSD output: the root element of the xsd.
To create the xsl trasformation between the file Database.xsd and anagrafica.xsd you can use [[XML Data mapper]] tool
{|
|-
| [[File:4buws.png|thumb|right|WebService Wizard fourth window]]
| [[File:5buws.png|thumb|right|WebService Wizard five window]]
| [[File:6buws.png|thumb|right|Xml data mapper]]
|}
== Web Service wizard ==
On service element choose bottom-up development method, on the opened page set the following parameter:
*Web Service name: getAnagrafica
*Target namespace operation: http://www.greenvulcano.it/greenvulcano
*Operation to bind: choose getAnagrafica - RequestReply
*choose soap trasport as protocol
*set input type Web Service: body (this indicate that the input at getAnagrafica service is only the body of soap request)
*set data provider name: domWSDataProvider
If you are familiary with soapui framework you can test the web service, the image "WebService soapui test" show how to.
{|
|-
| [[File:7buws.png|thumb|right|WebService Wizard first window]]
| [[File:8buws.png|thumb|right|WebService Wizard second window]]
| [[File:9buws.png|thumb|right|WebService Wizard third window]]
| [[File:10buws.png|thumb|right|WebService soapui test]]
|}

Roadmap

2012-02-13T14:28:13Z

G.iannello:

===RoadMap===

The engagement of GreenVulcano is to evolve the integration platform basing on the following criteria:

* Requests / Contributions from the community
* Specific needs of customers and developers
* Contributions of the partners / System Integrators

Our team adds its experience and expertise by offering innovative solutions in line with the vision that has always pushed us since our birth: simplicity and robustness.

GreenVulcano remains thus attached to the "real world", not in any way feeling the need to pursue or chasing at all costs the latest fashion trends of other products in the market.

The Roadmap is updated by our software architects and checked every six months.

===Version 3.2 (Q1 2012)===

1) “Sub Flow” management

2) BPEL Flows management

3) Every-component-Wizard on [[VulCon]] designer

4) Grafical Data Mapper

5) Drools integration

6) HL7 Adapter

7) New Wiki

===Version 3.3 (Q3 2012)===

1) Parallel flows

2) Grafical Try/Catch

3) Deploy and test from VulCon

===Version 3.4 (Q2 2013)===

1) Grafical Debugger

2) Service High availability and GV cluster management implementation

3) EJB 3.0 and Spring based version release

Roadmap

2012-02-13T14:24:15Z

G.iannello: /* RoadMap */

===RoadMap===

The engagement of GreenVulcano is to evolve the integration platform basing on the following criteria:

* Requests / Contributions from the community
* Specific needs of customers and developers
* Contributions of the partners / System Integrators

Our team adds its experience and expertise by offering innovative solutions in line with the vision that has always pushed us since our birth: simplicity and robustness.

GreenVulcano remains thus attached to the "real world", not in any way feeling the need to pursue or chasing at all costs the latest fashion trends of other products in the market.

The Roadmap is updated by our software architects and checked every six months.

===Version 3.2 (Q1 2012)===

1) “Sub Flow” management

2) BPEL Flows management

3) Every-component-Wizard on [[VulCon]] designer

4) Grafical Data Mapper

5) Drools integration

6) HL7 Adapter

7) New Wiki

===Version 3.3 (Q3 2012)===

1) Parallel flows

2) Grafical Try/Catch

3) Deploy and test from VulCon

===Version 3.4 (Q1 2013)===

1) Grafical Debugger

2) TBD

Roadmap

2012-02-13T14:23:31Z

G.iannello: Created page with "===RoadMap=== The engagement of GreenVulcano is to evolve the integration platform basing on the following criteria: * Requests / Contributions from the community * Specific ne..."

===RoadMap===

The engagement of GreenVulcano is to evolve the integration platform basing on the following criteria:

* Requests / Contributions from the community
* Specific needs of customers and developers
* Contributions of the partners / System Integrators

Our team adds its experience and expertise by offering innovative solutions in line with the vision that has always pushed us since our birth: simplicity and robustness.

GreenVulcano remains thus attached to the "real world", not in any way feeling the need to pursue or chasing at all costs the latest fashion trends of other products in the market.

The Roadmap is updated by our software architects and checked every six months.

===Version 3.2 (Q1 2012)===

1) “Sub Flow” management

2) BPEL Flows management

3) Every-component-Wizard on [[VulCon]] designer

4) Grafical Data Mapper

5) Drools integration

6) HL7 Adapter

7) New Wiki

===Version 3.3 (Q3 2012)===

1) Parallel flows

2) Grafical Try/Catch

3) Deploy and test from VulCon

===Version 3.4 (Q1 2013)===

1) Grafical Debugger

2) TBD

Adapters

2012-02-13T13:38:13Z

G.iannello: /* Description */

==Description==

The {{GVESB}} adapters, from now on GVAdapters, provide the implementations for connecting to external systems.

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

The following table shows the available GVAdapters and its application from user point of view:

{|class="gvtable"
! Adapter !! Description
|-
| [[GVWebServices]] (aka Gvaxis2) || {{GVESB}} Web Services definition
|-
| [[GVHL7ListenerManager]] || Adapter for enabling inbound and outbound connections using the HL7 protocol
|-
| [[GVForwards]] (in GVCore.xml) || {{GVESB}} JMS Forward configuration.
|-
| EJB Core ||
|-
| [[GVJBPMConfiguration]] ||
|-
| [[GVJbpmTaskListenerManager]] ||
|-
| [[GVConnectorConfiguration]] || {{GVESB}} client API configuration.
|-
| [[GVRulesConfigManager]] || Drools Rules set definition
|}

{{GVESB}} has also implemented other support functions listed bellow:
* [[GVSQLErrorMapping]]
* [[GVDataSources]]
* [[GVHTTPAdapter]]
* [[GVJdbc]]
* [[GVJDBCConnectionBuilder]]
* [[GVDataProviderManager]]
* [[GVDataHandlerConfiguration]]
* [[GVExcelWorkbookConfiguration]]
* [[GVExcelCreatorConfiguration]]
* [[GVBIRTReportConfiguration]]
* [[GVAdapterOpenSpCoop]].

GVWebServices

2012-02-13T13:35:02Z

G.iannello: /* {{VULCON}} / {{GVCONSOLE}} Configuration */

==Description==

The element GVWebServices allows to define the [[Web Services]] implemented by {{GVESB}}.

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

The GVWebServices Element is present in the {{VULCON}} Adapter view, as a GVAdapters subelement.

The following table shows GVWebServices element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| version || fixed || This attribute must assume the value '''1.0'''.
|-
| type || fixed || This attribute must assume the value '''module'''.
|-
| name || fixed || This attribute must assume the value '''WEB_SERVICES'''.
|}

Its subelements are:
* Description
* [[GVWebServices#GreenVulcanoWebServices|GreenVulcanoWebServices]]
* [[GVWebServices#BusinessWebServices|BusinessWebServices]]
* [[GVWebServices#UDDI|UDDI]]
* [[GVWebServices#AxisExtra|AxisExtra]]

===GreenVulcanoWebServices===

This element represents the {{GVESB}} Web Services definition.

Its subelements are:
* Description
* GreenVulcanoWebService

====GreenVulcanoWebService====

The key that identifies the service is given either by the field id-key, or by the triple [[system]]/[[service]]/[[operation]]:
* If this key is not satisfied we will use the default inputObjectDataProviders and outputObjectDataProviders
* If the defaults are not defined an exception will be thrown.

The following table shows the GreenVulcanoWebService element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || fixed || This attribute must assume the value '''greenvulcanowebservice'''.
|-
| id-key || optional || The attribute's value can't be null.
|-
| id-service || optional || Service
|-
| id-system || optional || System
|-
| id-primitive || required || Primitive to invoke. The attribute's admitted values are:
* Request
* RequestReply
* GetReply
* GetRequest
* SendReply
|}

===BusinessWebServices===

Business web services definition on Axis2.

The following table shows the BusinessWebServices element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| wsdl-directory || required || Directory containing the generated WSDL for the services exposed through Axis2.
|-
| services-directory || required || Directory containing the services generated from a WSDL using Axis2.
|-
| authenticated-http-soap-address || optional || This is the default URL that is used to build the soap:
address for [[Web Services]] that require authentication exposed with http protocol.
This URL can be overridden on different services.
If not specified will be required to define it on the services.
The final URL will be formed by concatenating the name of the service: default-soap-address/service
|-
| authenticated-https-soap-address || optional || This is the default URL that is used in the build the soap:address for web services that require authentication exposed with https protocol.
This URL can be overridden on different services.
If not specified will be required to define it on the services.
The final URL will be formed by concatenating the name of the service: default-soap-address/service
|-
| http-soap-address || optional || This is the default URL that is used in the build the soap:address for web services that not require authentication exposed with http protocol.
This URL can be overridden on different services.
If not specified will be required to define it on the services.
The final URL will be formed by concatenating the name of the service: default-soap-address/service
|-
| https-soap-address || optional || This is the default URL that is used in the build the soap:address for web services that not require authentication exposed with https protocol.
This URL can be overridden on different services.
If not specified will be required to define it on the services.
The final URL will be formed by concatenating the name of the service: default-soap-address/service
|}

Its subelements are:
* Description
* WebService

====WebService====

This element allows to define a business web services.

The following table shows the WebService element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| web-service || required || The attribute's value can't be null.
|-
| force-https || optional || The attribute's admitted values are:
* true
* false
|-
| soap-address || optional || Il soap:address will be exactly the here specified url.
As a difference with the default-soap-address, it won't be made any composition with the service name.
If default-soap-address is not specified, this is mandatory.
The attribute's value can't be null.
|-
| input-xsd || optional || The path of the XSD that defines the types of input that will be declared in the generated WSDL.
May contain an absolute path or a relative path, in which case, is relative to <nowiki>${{gv.app.home}}/xmlconfig/xsds.</nowiki>
May contain [[placeholders]]. May also include the types of output, in this case does not specify the parameter 'output-xsd'.
The attribute's value can't be null.
|-
| output-xsd || optional || The path of the XSD that defines the types of output that will be declared in the generated WSDL.
May contain an absolute path or a relative path, in which case, is relative to <nowiki>${{gv.app.home}}/xsds.</nowiki>
If not specified only the parameter 'input-xsd' will be used.
The attribute's value can't be null.
|-
| targetNS-from-xsd || optional || Defines if the target namespace of the types in the WSDL shall be that specified in the XSD input. If "false", the target namespace is: http://www.greenvulcano.it/greenvulcano
The attribute's admitted values are:
* true
* false
|-
| useOriginalwsdl || optional || The attribute's admitted values are:
* true
* false
|}

Its subelements are:
* Description
* [[GVWebServices#WSOperation|WSOperation]]
* [[GVWebServices#Transport|Transport]]
* [[GVWebServices#EngageModule|EngageModule]]

=====WSOperation=====

This element defines the Web Service Operation.

The following table shows the WSOperation element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| operation-qname || required || Qualified Name (QName) of the operation exposed by the web service.
If the namespace is present, it must be specified in braces:
{namespace}localname
|-
| soap-action || optional || MIME Header SOAPAction of the HTTP request.
If not specified is set to SERVICE/OPERATION
|-
| ref-dp || optional || DataProvider to be used for sending the reply to the caller.
The DataProvider will return a MessageContext to be sent as a reply.
If not used, the webservice adapter expects a org.apache.axiom.soap.SOAPEnvelope as a field object of GVBuffer.
|}

It has the subelements:
* Description
* [[GVWebServices#Binding|Binding]]
* [[GVWebServices#PolicyData|PolicyData]]

=====Binding=====

Defined by the triple gv-system/gv-service/gv-operation.

The following table shows the Binding element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| gv-service || required || ID service with which to perform the invocation of {{GVESB}}
|-
| gv-system || optional || ID system with which to perform the invocation of {{GVESB}}
|-
| gv-operation || required || {{GVESB}} operation to invoke.
|-
| transaction-timeout-secs || optional || Transaction timeout in seconds.
|-
| inputType || optional || Defines how to set the response data in the object field of output GVBuffer:
* context : the MessageContext
* envelope : the envelope as XML serialized as string
* body : the body as XML serialized as string
* body-element : the first child of body as XML serialized as string
* header : the header as XML serialized as string
* envelope-om : the envelope as OMMessage
* body-om : the body as OMMessage
* body-element-om : the first child of body as OMMessage
* header-om : the header as OMMessage
Default: context
|-
| transaction || optional || Indicates whether the invocation to be performed in {{GVESB}} is transactional or not.
The possible values are:
* none : The invocation is performed in non transactional mode.
* commit-before-reply : The invocation is performed in transactional mode and the commit is carried out immediately before returning the response to clients.
* commit-after-reply : The invocation is performed in transactional mode and the commit is carried out immediately after returning the response to clients.
|}

=====PolicyData=====

This element is an XML that describes the policies for a specific. Currently it is used only for the WS-Security implemented by the module 'rampart'.

Follows an example of policy to be included on the module 'rampart':
<syntaxhighlight lang="XML">
<wsp:Policy wsu:Id="UTOverTransport" xmlns:wsu="http://docs.oasis-open.org/
wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</sp:TransportToken>
<sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite>
<sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout>
<sp:IncludeTimestamp/>
</wsp:Policy>
</sp:TransportBinding>
<sp:SignedSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:UsernameTokensp:
IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"/>
</wsp:Policy>
</sp:SignedSupportingTokens>
<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
<ramp:user>alice</ramp:user>
<ramp:passwordCallbackClass>org.apache.rampart.samples.policy.sample01.PWCBHandler
</ramp:passwordCallbackClass>
</ramp:RampartConfig>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</syntaxhighlight>

The PolicyData Element is used by EngageModule, WSOperation.

The following table shows the PolicyData element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| policy_key || required || Defines the key to set the policy for the service invocation.
The attribute's admitted values are:
* rampartPolicy
|}

=====Transport=====

Transport configured for webservices.

Its subelements are:
* Description
* soap
* soap12
* rest : with the attributes
{|class="gvtable"
! Attribute !! Type !! Description
|-
| verb || optional || The attribute's admitted values are:
* GET
* POST
* PUT
* DELETE
|}
* jms : with the attributes
{|class="gvtable"
! Attribute !! Type !! Description
|-
| connectionFactory || optional ||
|-
| initialContextFactory || optional ||
|-
| jndiURL || optional ||
|-
| destination || optional ||
|-
| replyDestination || optional ||
|-
| destinationType || optional || The attribute's admitted values are:
* queue
* topic
|-
| contentType || optional ||
|-
| bytesMessage || optional ||
|-
| textMessage || optional ||
|}

=====EngageModule=====

The EngageModule Element is used by: AxisWebServiceInvoker and WebService.

The following table shows the EngageModule element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| name || required || Defines the name of a module to hire to handle WS-*.
If set, takes precedence over the attribute 'specifications'.
The attribute's admitted values are:
* rampart
* sandesha2
|-
| type || optional || Defines the class that implements the hander for the module to engage.
The attribute's default value is '''it.greenvulcano.gvesb.virtual.ws.module.DefaultModuleHandler'''.
The attribute's admitted values are:
* it.greenvulcano.gvesb.virtual.ws.module.rampart.RampartModuleHandler
* it.greenvulcano.gvesb.virtual.ws.module.sandesha2.Sandesha2ModuleHandler
The attribute's value can't be null.
|-
| specification || optional || The specification to implement, mandatory and other than 'NO-SPEC' if the name attribute is not declared.
The attribute's default value is: NO-SPEC.
The attribute's admitted values are:
* NO-SPEC
* WS-Security
* WS-ReliableMessaging
|}

Its subelements are:
* Description
* [[GVWebServices#PolicyData|PolicyData]]
* [[GVWebServices#ModuleProperty|ModuleProperty]]

=====ModuleProperty=====

This element set specific properties for the module to engage.

For example, the property 'org.apache.axis2.addressing.AddressingConstants.DISABLE_OUTBOUND_ADDRESSING_VALIDATION' setted to 'true' prevents a fault if SOAPAction is not set.

The following table shows the ModuleProperty element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| name || required || The attribute's value can't be null.
|-
| value || required || The attribute's value can't be null.
|-
| type || optional || The attribute's default value is: String.
The attribute's admitted values are:
* String
* Boolean
* Byte
* Short
* Int
* Long
* Float
* Double
|}

===UDDI===

The UDDI Element is used by: GVWebServices.

It has the subelements:
* Description
* JAXMLRegistry
* Proxy

====JAXMLRegistry====

{{GVESB}} implementation for the UDDI Server JUDDI.

The following table shows the JAXMLRegistry element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| class || fixed || This attribute must assume the value '''it.greenvulcano.gvesb.j2ee.xmlRegistry.impl.RegistryImpl'''.
|-
| type || fixed || This attribute must assume the value '''xmlregistry'''.
|-
| id-registry || required || Unique identifier of XMLRegistry
|-
| query-url || required || URL definition to perform the query
|-
| publish-url || required || Definition of the URL to make the publication
|-
| user-name || optional || Defining the user name for authentication on the Registry
|-
| password || optional || Defining the password for authentication on the Registry. #Encrypted
|-
| organization-name || optional || Defining the desired organization's name on the Registry
|}

Its subelements are:
* Description
* Properties

=====Properties=====

List of the properties needed to access the UDDI server.

Its subelements are:
* Description
* connectionFactory
* connectionProperty

=====connectionFactory=====

{{GVESB}} Connection Factory.

The following table show the connectionFactory element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| value || required || Full qualified name of the connection factory.
|}

=====connectionProperty=====

Defines a property to access the UDDI server.

The following table shows the connectionProperty element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || required || Property type.
|-
| name || required || Fully qualified interface name.
|-
| value || required || Fully qualified name of te implementation.
|}

=====Proxy=====

This element defines the Proxy configuration.

It is used by: [[Http-call#endpoint|endpoint]], '''UDDI''' and [[ws-call]].

The following table shows the Proxy element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| host || required || Proxy server IP or name.
|-
| port || optional || Proxy server port. Default: 80
|-
| user || optional || User name.
|-
| password || optional || User password. #Encrypted
|}

===AxisExtra===

The AxisExtra Element is used by: GVWebServices and it is visible from {{L_VULCON}} in the Adapter View.

Its subelements are:
* Description
* [[GVWebServices#PasswordCallback|PasswordCallback]]

====PasswordCallback====

Contains the PwCbBasicHandler items whose attributes are:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| type || fixed || This attribute must assume the value '''pwcb'''.
|-
| class || fixed || This attribute must assume the value '''it.greenvulcano.gvesb.ws.rampart.policy.pwcb.PwCbBasicHandler'''.
|}

The PwCbBasicHandler Element contains the subelements:
* Description
* [[GVWebServices#UserDef|UserDef]]

=====UserDef=====

Each UserDef Element allows to define an User.

The following table shows the UserDef element's attributes:
{|class="gvtable"
! Attribute !! Type !! Description
|-
| name || required || The attribute's value can't be null.
|-
| password || required || #Encrypted
|}

Post Installation

2012-02-13T13:32:56Z

G.iannello:

After [[Installation]] and configuration previously described, make sure that, in case of *nix systems, the user with which {{GVESB}} will be executed has permission for the following scripts:

: $GV_HOME/bin/start_GreenV.sh 
: $GV_HOME/bin/stop_GreenV.sh 
: $JBOSS_HOME/bin/run.sh 
: $JBOSS_HOME/bin/shutdown.sh

'''Finalizing the installation'''

If you have chosen to perform the installation by downloading the {{GVESB}} Package that does not include JBoss, you need to change some files with steps described below:
{| class="note"
|-
| [[File:info.png]]
| The ''jboss-service.xml'' is present in the following location:
: $GV_SERVER/conf
The variable gv.app.home defined in the script ''start'' indicates the home directory of the product.
|}

Add the following lines to the file ''jboss-service.xml'':
<syntaxhighlight lang="XML">

<classpath codebase="${gv.app.home}/application/lib" archives="*"/>
</syntaxhighlight>
before
<syntaxhighlight lang="XML">
<classpath codebase="${jboss.server.lib.url}" archives="*"/>
<classpath codebase="${jboss.common.lib.url}" archives="*"/>
</syntaxhighlight>

Change in the file the ''bootstrap/profile.xml'' the configuration of the ''mbean'' ''BootstrapProfileFactory'' as follows:
{| class="note"
|-
| [[File:info.png]]
| The file ''profile.xml'' is present in the following path:
:$GV_SERVER/conf/bootstrap
|}
<syntaxhighlight lang="XML">
<bean name="BootstrapProfileFactory" class="org.jboss.system.server.profileservice.repository.StaticProfileFactory">
<property name="bindingsURI">${jboss.server.home.url}conf/bindingservice.beans</property>
<property name="bootstrapURI">${jboss.server.home.url}conf/jboss-service.xml</property>
<property name="deployersURI">${jboss.server.home.url}deployers</property>
<property name="applicationURIs">
<list elementClass="java.net.URI">
<value>${jboss.server.home.url}deploy</value>

<value>file://${gv.app.home}/application/deploy</value>
</list>
</property>
<property name="attachmentStoreRoot">${jboss.server.data.dir}/attachments</property>
<property name="profileFactory"><inject bean="ProfileFactory" /></property>
</bean>
</syntaxhighlight>

Modify the file ''login-config.xml'' as follows:
{| class="note"
|-
| [[File:info.png]]
| The file ''login-config.xml'' is present in the following path:
:$GV_SERVER/conf
The files ''*.properties'' are present in the following path:
:$GV_HOME/xmlconfig
The ''OdeHsqlDbRealm'' needs a DataSource registered with name ''ds.ode'' usually configured in:
:$GV_HOME/application/deploy/gvesb-db-ds.xml
|}

<syntaxhighlight lang="XML">
<application-policy name="gvesb">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">
<module-option name="usersProperties">gvesb-users.properties</module-option>
<module-option name="rolesProperties">gvesb-roles.properties</module-option>
</login-module>
</authentication>
</application-policy>
<application-policy name = "OdeHsqlDbRealm">
<authentication>
<login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">ode</module-option>
<module-option name = "userName">ode</module-option>
<module-option name = "password">ode</module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=ds.ode</module-option>
</login-module>
</authentication>
</application-policy>
</syntaxhighlight>

{| class="note"
|-
| [[File:info.png]]
| The third part configurable components, in order to be integrated with {{GVESB}}, can be copied in the following directory:
: $GV_HOME/application/deploy
|}

When the installation procedure described above is finished, the file system will be structured as follows:
::'''$GV_HOME/'''
:::'''application/'''
::::'''deploy/''': contains the application components (ejb, war, ear) and the configuration files of the application server (JBoss) resources.
::::'''lib/''' : contains the {{GVESB}} support libraries.
:::'''BIRTReportEngine/''' :contains BIRT report definitions
:::'''BpelProcess/''' :contains ODE BPEL prosess definitions
:::'''doc/'''
::::'''extra/''' : contains the configuration files fragments and DDL scripts to enable logging, statistics and savepoints on various DataBases
::::'''licenses/''' : contains the license of the libraries used by {{GVESB}}
::::'''reference/''': contains the PDF files that are the {{GVESB}} configuration reference guides and XSD files that describe the internal structure of some {{GVESB}} XML
:::'''dtds/''' : contains the dtds used by {{L_GVCONSOLE}}/{{L_VULCON}} to validate the {{GVESB}} configuration
:::'''gvconsole/''': contains the {{L_GVCONSOLE}} work files and the configurations back-up
::::'''etc/'''
::::'''lock/'''
:::'''gvdte/''' : contains the transformations maps used by the {{GVESB}} DTE (Data Transformation Engine).
::::'''datasource/'''
:::::'''bin/''' : contains the maps for binary transformation (binary buffers <-> XML)
:::::'''xsl/''' : contains the maps for XSL transformations
:::::'''xsd/''' : contains the XSD file used to validate the transformations input/output
:::'''log/''' : contains the log files of the various {{GVESB}} subsystems, differentiated by the subsystem name and day. In this directory are generated the dumps of input/output buffers of services invoked by {{L_GVCONSOLE}}
:::'''Rules/''' : Drools rules definition files
:::'''webservices/'''
::::'''modules/''' : contains the MAR files that defines the extra modules for AXIS services
::::'''services/''' : contains the AAR files that defines the WebService published by {{GVESB}}
:::'''xmlconfig/''': contains the {{GVESB}} configuration XML files and the license enabling the adapters for the Enterprise version.
::::'''js/''' : contains the JavaScript files used to create pre-configured execution contexts
::::'''wsdl/''' : contains the WSDL files of the WebService published and invoked by {{GVESB}}
::::'''xsds/''' : contains the XSD files used in the WSDL service published by {{GVESB}} and the validation of XML documents.

::'''$JBOSS_HOME/'''
:::'''bin/'''
:::'''client/'''
:::'''common/'''
:::'''docs/'''
:::'''lib/'''
:::'''server/'''
::::'''GreenV/''' --> alias '''$GV_SERVER'''
:::::'''conf/'''
:::::'''deploy/'''
:::::'''lib/'''
:::::'''lib/''' : JBoss server log directory

GetAnagrafica ws bottom-up method

2012-02-13T13:30:45Z

G.iannello: /* SERVICE SECTION */

We start from a {{GVESB}} service "getAnagrafica" that simply returns the anagrafica presents in table Anagrafica.

== SYSTEM SECTION ==
The first image shows how create an operation system section.
In the tag system define a new Channel "CH_DB" and add a [[db-call]] operation, in [[db-call]] operation set the parameters for the Element DBOoperation, Statement and ResultSet:
*[[DBOoperation]]-->[[DataSourceConnection]]
**jndi-name: insert the name of jndi DataSource in this example ds.anagrafica
*Statement
**StatementValue: in this field insert the following query "select cognome,nome,citta from anagrafica"
*[[ResultSet]]-->[[Formatters|QueryFormatter]]
**type: choose base_formatter
**structure: ONLY_DATA, remember if you don't want also metadata form query select for filed structure the value ONLY_DATA
{|
|-
| [[File:1buws.png|thumb|WebService Wizard first window]]
| [[File:2buws.png|thumb|WebService Wizard second window]]
| [[File:3buws.png|thumb|WebService Wizard third window]]
|}
The system section has been configured

== SERVICE SECTION ==

This section shows the getAnagrafica service configuration. On the elements [[Service]] add a service with name "getAnagrafica"

[[File:4buws.png|thumb|left|WebService Wizard fourth window]]

GetAnagrafica ws bottom-up method

2012-02-13T13:30:17Z

G.iannello: /* SERVICE SECTION */

We start from a {{GVESB}} service "getAnagrafica" that simply returns the anagrafica presents in table Anagrafica.

== SYSTEM SECTION ==
The first image shows how create an operation system section.
In the tag system define a new Channel "CH_DB" and add a [[db-call]] operation, in [[db-call]] operation set the parameters for the Element DBOoperation, Statement and ResultSet:
*[[DBOoperation]]-->[[DataSourceConnection]]
**jndi-name: insert the name of jndi DataSource in this example ds.anagrafica
*Statement
**StatementValue: in this field insert the following query "select cognome,nome,citta from anagrafica"
*[[ResultSet]]-->[[Formatters|QueryFormatter]]
**type: choose base_formatter
**structure: ONLY_DATA, remember if you don't want also metadata form query select for filed structure the value ONLY_DATA
{|
|-
| [[File:1buws.png|thumb|WebService Wizard first window]]
| [[File:2buws.png|thumb|WebService Wizard second window]]
| [[File:3buws.png|thumb|WebService Wizard third window]]
|}
The system section has been configured

== SERVICE SECTION ==

[[File:4buws.png|thumb|left|WebService Wizard fourth window]]
This section shows the getAnagrafica service configuration. On the elements [[Service]] add a service with name "getAnagrafica"

GetAnagrafica ws bottom-up method

2012-02-13T13:29:54Z

G.iannello: /* SERVICE SECTION */

We start from a {{GVESB}} service "getAnagrafica" that simply returns the anagrafica presents in table Anagrafica.

== SYSTEM SECTION ==
The first image shows how create an operation system section.
In the tag system define a new Channel "CH_DB" and add a [[db-call]] operation, in [[db-call]] operation set the parameters for the Element DBOoperation, Statement and ResultSet:
*[[DBOoperation]]-->[[DataSourceConnection]]
**jndi-name: insert the name of jndi DataSource in this example ds.anagrafica
*Statement
**StatementValue: in this field insert the following query "select cognome,nome,citta from anagrafica"
*[[ResultSet]]-->[[Formatters|QueryFormatter]]
**type: choose base_formatter
**structure: ONLY_DATA, remember if you don't want also metadata form query select for filed structure the value ONLY_DATA
{|
|-
| [[File:1buws.png|thumb|WebService Wizard first window]]
| [[File:2buws.png|thumb|WebService Wizard second window]]
| [[File:3buws.png|thumb|WebService Wizard third window]]
|}
The system section has been configured

== SERVICE SECTION ==

[[File:4buws.png|thumb|WebService Wizard fourth window]]
This section shows the getAnagrafica service configuration. On the elements [[Service]] add a service with name "getAnagrafica"

GetAnagrafica ws bottom-up method

2012-02-13T13:29:30Z

G.iannello: /* SYSTEM SECTION */

We start from a {{GVESB}} service "getAnagrafica" that simply returns the anagrafica presents in table Anagrafica.

== SYSTEM SECTION ==
The first image shows how create an operation system section.
In the tag system define a new Channel "CH_DB" and add a [[db-call]] operation, in [[db-call]] operation set the parameters for the Element DBOoperation, Statement and ResultSet:
*[[DBOoperation]]-->[[DataSourceConnection]]
**jndi-name: insert the name of jndi DataSource in this example ds.anagrafica
*Statement
**StatementValue: in this field insert the following query "select cognome,nome,citta from anagrafica"
*[[ResultSet]]-->[[Formatters|QueryFormatter]]
**type: choose base_formatter
**structure: ONLY_DATA, remember if you don't want also metadata form query select for filed structure the value ONLY_DATA
{|
|-
| [[File:1buws.png|thumb|WebService Wizard first window]]
| [[File:2buws.png|thumb|WebService Wizard second window]]
| [[File:3buws.png|thumb|WebService Wizard third window]]
|}
The system section has been configured

== SERVICE SECTION ==

[[File:4buws.png|thumb|WebService Wizard fourth window]]
This section show the getAnagrafica service configuration. On the elements [[Service]] add a service with name "getAnagrafica"

HL7

2012-02-10T16:13:47Z

G.iannello: /* Inbound HL7 Connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[File:1100px-ChannelHl7.png|thumb|center|256px]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[File:1100px-ServizioHl7.png|thumb|center|256px]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[File:TrasfHl7.png|thumb|center|256px]]

[[File:1100px-Mapping.png|thumb|center|256px]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[File:1100px-ListnerHl7.png|thumb|center|256px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[File:1100px-ListenerServiceHl7.png|thumb|center|256px]]

HL7

2012-02-10T16:13:22Z

G.iannello: /* Outbound HL7 connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[File:1100px-ChannelHl7.png|thumb|center|256px]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[File:1100px-ServizioHl7.png|thumb|center|256px]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[File:TrasfHl7.png|thumb|center|256px]]

[[File:1100px-Mapping.png|thumb|center|256px]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[File:1100px-ListnerHl7.png|thumb|center|512px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[File:1100px-ListenerServiceHl7.png|thumb|center|512px]]

HL7

2012-02-09T16:00:43Z

G.iannello:

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png]]

[[Image:1100px-Mapping.png]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png]]
<ol>

HL7

2012-02-09T15:52:32Z

G.iannello: /* Inbound HL7 Connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png | thumb]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png | thumb]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png | thumb]]

[[Image:1100px-Mapping.png | thumb]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png | thumb]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png | thumb]]
<ol>

HL7

2012-02-09T15:51:57Z

G.iannello: /* Outbound HL7 connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png | thumb]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png | thumb]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png | thumb]]

[[Image:1100px-Mapping.png | thumb]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png|1100px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png|1100px]]
<ol>

HL7

2012-02-09T15:51:19Z

G.iannello: /* Outbound HL7 connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png | thumb]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png|1100px]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png]]

[[Image:1100px-Mapping.png|1100px]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png|1100px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png|1100px]]
<ol>

GVBuffer

2012-02-09T13:39:41Z

G.iannello: /* Description */

==Description==
The GVBuffer data structure (it.greenvulcano.gvesb.buffer.GVBuffer) represents the container that carries information within the components of {{GVESB}}:

Inbund Adapter <-> Core <-> Plug-in outbound

The business information traveling in the 'object', the GVBuffer data structure can contain any visual data type: JMS messages, SOAP Envelope, Document, strings, arrays of bytes, etc..
The data structure contains properties specific of {{GVESB}} platform :
*[[Service]]: service invoked
*[[System]]: the system client identifier that invokes the service
*Id: the identifier of the particular transaction (eg, to identify the response of a specific asynchronous request)
*RetCode: return code of the service invocation (possibly defined by contract client / server for a specific service)
GVBuffer The data structure also offers the ability to define and modify the properties specific service within the workflow to be used by JavaScript and / or OGNL and conditions as routing.

==Structure==
[[File:GVBuffer.png|thumb|WebService Wizard first window]]

{{GVBUFFER}}s have all the same shape, based on three primary components, the following image describe this components.
*Platform fields, this buffer section contains all information to indentify the flow
*Properties, this section contains an object thats maps keys to values. This object cannot contain duplicate keys; each key can map to at most one value.
*Payload, This buffer section contains all information to indentify the flow

A single service can have more GvBuffer, each operation (node) in a Greenvulcano service can declare a {{GVBUFFER}} as input and/or output operation. A {{GVBUFFER}} can be also overwritten by another operation. To define a {{GVBUFFER}} simply insert its identifier as input or output node's property.

====Example====
In the example below is shown a flow composed of Four nodes. The first one presents an incoming {{GVBUFFER}} associated to the identifier 'to_process'; the result of the node will be into another {{GVBUFFER}} associated to the identifier 'data'. Subsequent nodes will work on the same buffer ('data'), which will be the output parameter of the <GVEndNode>: so information in it will be delivered to the client.

<syntaxhighlight lang="XML">
<Flow first-node="extract_data" point-x="19" point-y="137">
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
dump-in-out="false" id="extract_data"
id-system="CREDIT" input="to_process"
next-node-id="add_ext" op-type="call"
operation-name="CreditCards" output="data"
point-x="149" point-y="140" type="flow-node"/>
<ChangeGVBufferNode class="it.greenvulcano.gvesb.core.flow.ChangeGVBufferNode"
dump-in-out="false" id="add_ext" input="data"
next-node-id="send_email"
op-type="change GVBuffer" point-x="309"
point-y="137" type="flow-node">
<ChangeGVBuffer clear-data="false">
<PropertyDef name="FILE_EXT"
value="decode{{ognl{{property['BIRT_REPORT_TYPE']}}::excel::xls::pdf}}"/>
</ChangeGVBuffer>
</ChangeGVBufferNode>
<GVOperationNode class="it.greenvulcano.gvesb.core.flow.GVOperationNode"
dump-in-out="false" id="send_email"
id-system="CREDIT" input="data"
next-node-id="end" op-type="call"
operation-name="SendEmailSVCResponse"
output="data" point-x="473" point-y="137"
type="flow-node"/>
<GVEndNode class="it.greenvulcano.gvesb.core.flow.GVEndNode"
end-business-process="yes" id="end" op-type="end"
output="data" point-x="671" point-y="137"
type="flow-node">
<ChangeGVBuffer clear-data="true"/>
</GVEndNode>
</Flow>
</syntaxhighlight>

HL7

2012-02-09T13:30:09Z

G.iannello: /* Inbound HL7 Connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png|1100px]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png]]

[[Image:1100px-Mapping.png|1100px]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png|1100px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png|1100px]]
<ol>

HL7

2012-02-09T13:29:39Z

G.iannello: /* Outbound HL7 connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png|1100px]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png]]

[[Image:1100px-Mapping.png|1100px]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listner, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png|1100px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png|1100px]]
<ol>

HL7

2012-02-09T13:28:41Z

G.iannello: /* Outbound HL7 connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to define a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png|1100px]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a tranformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png]]

[[Image:1100px-Mapping.png|1100px]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listner, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png|1100px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png|1100px]]
<ol>

HL7

2012-02-09T13:27:52Z

G.iannello: /* HL7 Connector */

==Overview==
[http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

* Created to exchange information related to patients
* Standardizes the health system at clinical data exchange level
* Provides interfaces that allow the data flow through various systems
* Makes the health interoperability possible

==Message structure==
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.

==HL7 Connector==
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x.
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.

Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.

The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.

{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.

==Outbound HL7 connector==

Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]].

These are the easy steps to follow to defiine a HL7 [[Channel]]:

Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]]

[[Image:1100px-ChannelHl7.png]]

* host: hostname or IP address of the HL7 application waiting for the message
* name: [[Virtual Layer]] [[operation]] name
* port: application HL7 port
* timeout: channel HL7 timeout

Definition of a service for the invocation of the defined HL7 [[channel]]:

[[Image:1100px-ServizioHl7.png|1100px]]

The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc.
The HL7 connector manages the messages transforming them into XML messages.

For the mapping from a generic message to a HL7 message it is possible to define a tranformation map through [[XML Data mapper | VulCon]] tool.
To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:

[[Image:TrasfHl7.png]]

[[Image:1100px-Mapping.png|1100px]]

==Inbound HL7 Connector==
The inbound HL7 connector allows the definition of a HL7 message listner, associating the message reception to a {{GVESB}} [[service]].
The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.

The easy steps to follow to define an HL7 [[channel]] are the following:

Definition of a filter to apply to every received HL7 message:
[[Image:1100px-ListnerHl7.png|1100px]]

Association to a HL7 message to the [[service]] defined on {{GVESB}}:
[[Image:1100px-ListenerServiceHl7.png|1100px]]
<ol>