... SwitchYard Context

Introduction

Holds contextual information around the exchange of messages between a service consumer and provider. SwitchYard context resembles Camel Context and in the execution of a Camel Component delegates/extends CamelContext.

It is just a placeholder for name/value pairs, but internally holds Property objects consisting of a name, scope, value and labels.

• Interface definition is org.switchyard.Context.
• Default implementation is org.switchyard.internal.CompositeContext

Context has scopes (Message and Exchange) and the life of this contexts is bound to the life of the scope it defines.

• A property defined with Scope.MESSAGE will live as long as the Message that defined the property lives.
• A property defined with Scope:EXCHANGE will live for the entire life of the Exchange, surviving every message that is sent to the Exchange.

You can get a property from the context in a specific scope with getProperty(String name, String scope) or regardless of the scope with getProperty(String name)

You can add a property, label a property, remove a property in one scope, in any scope, all the properties,…​

Labels

Labels are a way to mark a Context Property, and relate it to a SwitchYard funtcionality.

Base class is org.switchyard.label.Label

There are 5 types of labels (OOTB):

• BehaviorLabel: Marks the property relative to certain actions and/or behavior. (Copy of context,…​) (label type:behavior)
  • TRANSIENT: the property will not be preserved in a copy of the Exchange via Context.copy()
• ComponentLabel: Marks the property relative to certain component (label type: component)
  • CAMEL, HORNETQ, HTTP, JCA, RESTEASY, SOAP
• EnpointLabel: Marks the property relative to Endpoint related actions (context composition, message composers,…​) (label type: endpoint)
  • AMQP, ATOM, DIRECT, FILE, FTP, FTPS, HTTP, JCA, JMS, JPA, MAIL, MOCK, QUARTZ, REST, SEDA, SFTP, SOAP, SQL, TCP, TIMER, UDP, URI
• HttpInvokerLabel: Marks the property to be used as a header in the HTTPInvoker (label type: httpinvoker)
  • HEADER
• PropertyLabel: Marks the type of the property. It is used in JMS to mark JMS Properties or JMS Headers (label type:property).
  • HEADER, PROPERTY

SwitchYard labels

A label is composed following this rule:

prefix.<lowercase(label_type)>.<lowercase(label_name)>

• prefix: "org.switchyard.label."
• label type: (behavior, component, endpoint, httpinvoker, property)
• label name: (TRANSIENT, CAMEL, HTTP, JCA,…​.., HEADER, PROPERTY)

Examples:

org.switchyard.label.behavior.transient
org.switchyard.label.endpoint.http
org.switchyard.label.endpoint.soap
org.switchyard.label.component.soap
org.switchyard.label.property.header

Usage

SwitchYard uses the context for 3 main purposes:

• Storing internal information for the engine to work (defining behavior, lifecycle, …​). Every SwitchYard defined property is named with org.switchyard. prefix
• Binding components store information in the Context (camel components mainly)
• User specific storage of information.

SwitchYard usage of the Context

SwitchYard stores information in the context, in the appropiate Scope to model its behavior. It uses labels to mark the context of the information in the context, and to be able to remove the properties from the context when appropriate. Some of the functionalities in the Context and Labels are not meant to be used by users, only by SwitchYard internals, although they are defined in the same place.

User usage of the Context

User is subject to store information in the Context, also to model the application behavior in terms of user functionality. A user can use the Context in every SwitchYard component, in the MessageComposers and ContextMappers, transformers,…​ but how to access the context varies.

Components

Java

You can Inject the Context in any Java Component (Service Implementation) by using the @Component annotation

Camel

SwitchYard context properties are mapped to the Exchange properties and Message headers based on the scope (Scope.MESSAGE, Scope.EXCHANGE). There is no need to interact with the SwitchYard context in a Camel component.

• SwitchYard Exchange Properties are mapped to Camel Properties.

 from("xxx")
.setProperty("MyHeader", "MyValue")
.to("yyy");

• SwitchYard Message Properties are mapped to Camel Message Headers.

 from("xxx")
.setHeader("MyHeader", "MyValue")
.to("yyy");

BPMN/Rules

There are some Implicit Variables when defining the "from" in mappings from SY to Component.

• context: The current org.switchyard.Context.
• message: The current org.switchyard.Message.

Some examples:

from="message.content" - This is the same as message.getContent().
from="context[‘foo’]" - This is the same as context.getProperty("foo", Scope.MESSAGE).getValue(), in a null-safe manner.

BPEL

TODO

MessageComposers

In a MessageComposer you have the Exchange as a parameter to compose/decompose methods, so to get access to the context you can:

context = exchange.getContext();

ContextMappers

In a ContextMapper you have the Context as a parameter to mapFrom/mapTo methods.

Transformers

If you need to get access to the context in a SwitchYard transformer, you can qualify the "from" and use Message as input type in the transformer method.

@Transformer(from = "java:com.example.ClassOne")
public ClassTwo transform(Message message) {
   Context context = message.getContext();
   ....
   return classTwo;
 }

ExchangeInterceptors

In ExchangeInterceptors you have the Context as a parameter to before/after methods.

How is the information stored in the Context

Once you have access to the Context, every Property looked up in the context (if looked up without explicitly passing a Scope) will be first looked up as Message scoped and the as Exchange scoped. If the user sets a property without explicitly targeting a Scope, this Property will be defined as Message scoped.

Some examples of Context usage:

Context context = exchange.getContext();
context.setProperty("BindingName", gatewayName, Scope.MESSAGE);
context.setProperty("org.switchyard.exchangeGatewayName");   // This property will be Message scoped

context.getProperty("org.switchyard.exchangeGatewayName", Scope.Exchange);
context.getProperty("BindingName");   // Will return Message scoped property if defined, or then Exchange scoped

context.getProperties(); // Will provide with a Set<Property> with every property in every context
context.getProperties(Scope.EXCHANGE); // Will provide with a Set<Property> with every property in EXCHANGE context

context.removeProperties(); // Clears out the context
context.removeProperties(Scope.MESSAGE); // Clears out the MESSAGE Scope context
context.removeProperties(Label); // Removes every property in every context with that Label

Exchange context

This is a graphical representation of the Exchange context

Exchange Context ->
    CamelBatchComplete .............................: true
    CamelBatchIndex ................................: 0
    CamelBatchSize .................................: 1
    org.switchyard.bus.camel.consumer ..............: ServiceReference [name={....}]
    org.switchyard.bus.camel.contract ..............: org.switchyard.metadata.BaseExchangeContract@49cb9565
    org.switchyard.bus.camel.dispatcher ............: org.switchyard.bus.camel.ExchangeDispatcher@65994f93
    org.switchyard.bus.camel.labels ................: {CamelFileExchangeFile=[org.switchyard.label.component.camel, org.switchyard.label.endpoint.file],...., org.switchyard.security.context.SecurityContext=[org.switchyard.label.behavior.transient]}
    org.switchyard.bus.camel.phase .................: IN
    org.switchyard.bus.camel.replyHandler ..........: org.switchyard.component.camel.CamelResponseHandler@54a37b1a
    org.switchyard.exchangeGatewayName .............: file1
    org.switchyard.exchangeInitiatedNS .............: 10999671294181171
    org.switchyard.security.context.SecurityContext : DefaultSecurityContext@1210402593[systemUUID=455e975a-de16-4450-ac34-4b358fe1915d, expirationMillis=0, credentials=[], securityDomainsToSubjects={}]

Message Context

This is a graphical representation of the Message context

Exchange Context ->
Message Context ->
    BindingName .........................: file1
    CamelFileAbsolute ...................: true
    CamelFileAbsolutePath ...............: /input
    CamelFileLastModified ...............: 1412686922000
    CamelFileLength .....................: 702
    org.switchyard.bus.camel.labels .....: {CamelFileAbsolutePath=[org.switchyard.label.component.camel, org.switchyard.label.endpoint.file], ...., CamelFileLength=[org.switchyard.label.component.camel, org.switchyard.label.endpoint.file]}
    org.switchyard.bus.camel.messageSent : true
    org.switchyard.messageComposer ......: com.xxx.MyMessageComposer@1a6a1e9f
    timeIn ..............................: 20141007150250407

User defined labels

A user might want to create a label to mark and to add/remove information that they add in an easy way. It is just a matter of defining a new subclass of Label, and add the enumeration of labels needed.

In this way, a user can add information into the context, and then remove all of their information at once:

context.addProperty("userTransactionId","x12fd25", Scope.EXCHANGE, UserDefined.USER.label());
...
context.removeProperties(UserDefined.USER.label());

... message composers in SwitchYard

Message composition

It is the process of converting the Message from the binding format (HTTP request, SOAP envelope, JMS message, File, …​) to a SwitchYard message, and mapping the context information from the binding format (HTTP headers, SOAP headers, JMS headers, …​) to the SwitchYard Context, and from the Switchyard internal format (message and context) back again into the binding format.

Message Composition Explained with an example

Here we will find a description of what is happening at the message composition time in a call to a SwitchYard application through an HTTP binding and having one call to an external reference through an HTTP binding.

(1) Request message from binding to service

The request message is converted from the binding message type to the internal service type. For this to happen, a call toHttpMessageComposer.compose().

In this method two things will happen:

• It will create a Message for the Exchange.
• A call to HttpContextMapper.mapFrom(HttpRequestBindingData, context) will be done. This method will:
  • It will copy requestInfo from the HTTPRequestBindingData into the message Context with keyHttpComposition.HTTP_REQUEST_INFO and assigning the following labels, ComponentLabel.HTTP andEndpointLabel.HTTP

HttpRequestInfo has all the required information from the request, and is the source of information that can be used in the SwitchYard’s component implementations to access information relative to the request, such as requestURI, requestPath, method, contextPath,…​ See the implementation of this class to find all the available information.

• It will copy all headers from the HTTP request that match the defined includes and exludes regex pattern for the composer at design time.

Headers are not automatically copied, you have to add to messageComposer which headers you want to include (.*: all)

When checking for headers, or defining headers in Binding’s RegEx Inclusion and Exclusion, all headers arelowercased. If you send a header Authorization, you should check for authorization instead.

• It will copy the content from the HttpBindingData to the Message that will flow through SwitchYard converting it to the appropiate type.
• It will return the Message.

(2) Service component implementations execution

The request pipelines of a component will be executed, until a there is a call to an external HTTP service.

(3) Request message from reference to binding

A call to the external service is about to happen, and message needs to be converted from SwitchYard message to the reference binding data.

• A call to HttpMessageComposer.decompose(Exchange, HttpRequestBindingData) will be done. This method will:
  • Copies the content from the Exchange to the content HttpRequestBindingData
  • Calls HttpContextMapper.mapTo(Request) to copy headers from the Message`s Context to the HttpRequestBindingData’s http headers. These properties will be copied only if they match the registered regexp expressions in the MessageComposer’s design time configuration or if the properties are marked with the EndpointLabel.HTTP label in the Context.

(4) Response message from binding to reference

Once the external service has being executed, we have to deal with the response from this external service, and map it back into SwitchYard. To to this, a call to *HttpMessageComposer.compose(HttpResponseBindingData, Exchange) will be done. This method will:

• Create a Message
• Call HttpContextMapper.mapFrom(HttpResponseBindingData, Message) that will:
  • Copies the statusCode of the invocation into a Context property calledHttpContextMapper.HTTP_RESPONSE_STATUS with labels http (ComponentLabel.HTTP and EnpointLabel.HTTP)
  • It will copy all headers from the HTTP response that match the defined includes and exludes regex pattern for the composer at design time.

Headers are not automatically copied, you have to add to messageComposer which headers you want to include (.*: all)

• It will copy the content from the HttpBindingData to the Message that will flow through SwitchYard converting it to the appropiate type.
• It will return the Message.

(5) Service execution

The rest of the components` pipeline will be executed.

(6) Response message from service to binding

When our application has ended it’s execution and it is returning the result to the caller, it will call againHttpMessageComposer.decompose(Exchange, HttpResponseBindingData) to convert the SwitchYard message to the binding message or content. It will: * Get statusCode from Context propertyHttpContextMapper.HTTP_RESPONSE_STATUS that has been established as part of the SwitchYard service execution.

This property could be the one that was set from the invocation to the external Composite’s Reference. (In step 4)

• If there is no statusCode set as a property, or this statusCode property does not have the EndpointLabel.HTTP label, it will calculate one depending on the content and on the Exchange.getState. If the state of the Exchange isExchangeState.FAULT it will return an HTTP Error code of 500. (See the code for the logic determining the statusCode)
  • Copy the content from the SwitchYard’s Message to the HttpResponseBindingData
  • Call HttpContextMapper.mapTo(HttpResponseBindingData) that will:
    • Copy headers from the Message`s Context to the HttpRequestBindingData’s http headers. These properties will be copied only if they match the registered regexp expressions in the MessageComposer’s design time configuration or if the properties are marked with the EndpointLabel.HTTP label in the Context.
    • If the property is HttpContextMapper.HTTP_RESPONSE_STATUS it will set the status on the HttpResponseBindingData

... service with variable number of bindings in SwitchYard

Variable bindings

What we are trying to achieve is a functionality in where we have a generic application (I216_APP) that does some common logic with the contents of some files read from the filesystem. The files that this application has to read depends on the main "role" of the platform, so it can be "Local" or "Global" or both. We want to deploy a an application that there is no need to be modified to make it work in both 3 of the scenarios. As endpoint url are defined at application start up, and number of bindings in any application is fixed, we have following options:

• Mock the endpoints. Endpoints not available on specific geography will be mocked, that will incurr on useless polling and wasting of resources.
• Split implementations according to geography. Tight coupling between implementation and geography and duplication of code.
• Stop bindings per "role". Difficult to make automated. Tight coupling between implementation and geography and duplication of code.

Proposed solution

Create 2 new applications that will contain the appropiate file bindings per role, "global" and "local", that will read the files and delegate into the real I216_APP.

This I216_APP service binding will then be changed to SCA, so can be called locally from any other application (with minimal cost).

Implement a direct routing in the new applications with following logic:

from("switchyard://FileService")
.to("switchyard://I216_APP")

In this way, this new applications (file services) will have the responsibility of reading the corresponding files per platform role, "local" or "global".

Local role

In this platform role scenario, only the I216_APP_Local and I216_APP applications will be deployed, and will allow the platform to read "local" files and delegate the processing responsibility to the I216_APP.

Global role

In this platform role scenario, only the I216_APP_Global and I216_APP applications will be deployed, and will allow the platform to read "global" files and delegate the processing responsibility to the I216_APP.

Local + Global role

In this platform role scenario, the 3 applications will be deployed altogether, and will allow the platform to read "local" files and "global" files and delegate the processing responsibility to the I216_APP.

... how to install default workflows for FSW 6.0

Hi,
FSW 6.0 comes with a nice graphical installer that will install SwitchYard, RTGov and DTGov (S-RAMP). It happens, that DTGov comes with some sample workflows to demonstrate how the product works, but these workflows are not installed by default, so they need to be installed after FSW installation has finished.
You can do one of two approaches:

Deploy with maven

Navigate to jboss-eap-6.1/dtgov-data and create a local settings.xml containing the user credentials for the S-RAMP repository. This file must also contain the Overlord admin password that you configured during installation. Here is an example:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>local-sramp-repo</id> <username>admin</username> <password><YOUR_PASSWORD></password> </server> <server> <id>local-sramp-repo-snapshots</id> <username>admin</username> <password><YOUR_PASSWORD></password> </server> </servers> </settings>

Ensure that the server is up and running, and deploy the "SimpleReleaseProcess" sample workflow to the server by running the following command:

mvn -s local-settings.xml deploy

Install with s-ramp cli

These are the commands to to the installation:

s-ramp:connect http://localhost:8080/s-ramp-server admin <YOUR_PASSWORD> s-ramp:upload dtgov-workflows-1.0.1.Final-redhat-8.jar KieJarArchive s-ramp:property set maven.groupId org.overlord.dtgov s-ramp:property set maven.artifactId dtgov-workflows s-ramp:property set maven.version 1.0.1.Final-redhat-8 s-ramp:property set maven.type jar s-ramp:updateMetaData quit

NOTE: The artifact that you upload needs to have in META-INF/maven (somewhere in there) a pom.properties with the artifact GAV (GroupId, ArtifactId, Version), otherwise there is an exception very difficult to track down. 

... FSW documentation

Hi,
I have started to write down the documentation I'm creating in my github.
Documentation is written in asciidoc format, so github plugin for asciidoc makes it easily readable from there, and displays much nicely than in blogger, for which I should provide a template (css), but I do not time.

If you follow the project you will be updated with latest information, tips and tricks I collect.

I hope somebody finds it useful.

By the way, some of the tips and tricks from JUnit in SwitchYard has been incorporated into the official docs for next release :-D

... Configuration in SwitchYard

Configuration (Properties)

SwitchYard supports configuration properties, that can be injected into configuration or into service implementations:

Switchyard model configuration

SwitchYard allow you to replace any attribute or element value in switchyard.xml with a property from the runtime environment. The syntax for a replaced token is "${varname}" where "varname" is your property name. The configuration layer in SwitchYard is configured with instances of PropertyResolver, which are used to resolve the value of a property based on its name.

Property resolution order

Property values are resolved from the following locations:

• System properties passed by -D option of Java VM like "-Dproperty.name=property.value"
  
• System environment variables, referenced with an "env." prefix, for example: env.PATH
  
• Unit test properties
  
• JBoss AS7 properties, including access into the SecurityVault
  
• Domain properties in switchyard.xml
  
• SCA property definitions in the composite or component
  

The priority in resolving a property is from top to bottom, so a property defined as a System property will always take precedence over a property defined at domain or composite, and a property at domain level will olways take precedence over a property defined at component level.

Injecting properties into Service Implementation

Implementation properties allow you to inject one or more property values into a service implementation. This is based on the property support in the SCA assembly spec. Since the property is injected into service implementation logic, the injection mechanism itself is unique to each implementation type. The details for each implementation type follow:

• Java: injected using @Property into a CDI bean
  
• Camel: wired into Camel properties component and accessible in a Camel route using Camel’s own varName property notation
  
• BPEL: mapped into process variables via an <assign> with using resolveProperty() XPath custom function
  
• BPMN 2: inserted into process variables by data input associations
  
• Drools: available in a global map
  

Injecting properties in Java Bean implementations

Implementation properties represent environmental properties that you have defined in the SwitchYard application descriptor (switchyard.xml) for your bean implementation. Implementation properties in SwitchYard are the properties that you can configure on a specific service implementation. That is, you can make the property value available to service logic executing inside an implementation container. Here is an example:

<sca:component name="SimpleServiceBean">
      <bean:implementation.bean class="com.example.switchyard.switchyard_example.SimpleServiceBean"/>
      <sca:service name="SimpleService">
        <sca:interface.java interface="com.example.switchyard.switchyard_example.SimpleService">
          <properties>
            <property name="userName" value="${user.name}"/>
          </properties>
        </sca:interface.java>
      </sca:service>
</sca:component>

To access the Implementation Properties, add an @Property annotation to your bean class identifying the property you want to inject:

@Service(SimpleService.class)
public class SimpleServiceBean implements SimpleService {

  @Property(name="userName")
  private String name;

  @Override
  public String sayHello(String message) {
        return "Hello " + name + ", I got a message: " + message;
    }

}

Injecting Implementation Properties in Camel Routes

SwitchYard integrates with the Properties Component in Camel to make system and application properties available inside your route definitions. You can inject properties into your camel route using {{propertyname}} expression, where propertyName is the name of the property. For example, the following camel route expects the user.name property to be injected in the last <Log> statement:

<route xmlns="http://camel.apache.org/schema/spring" id="CamelTestRoute">
    <log message="ItemId [${body}]"/>
    <to uri="switchyard://WarehouseService?operationName=hasItem"/>
    <log message="Title Name [${body}]"/>
    <log message="Properties [{{user.name}}]"/>
</route>

Injecting Implementation Properties in BPEL

You can inject properties into your BPEL process definition with using SwitchYardPropertyFunction.resolveProperty() XPath custom function.

This bpel:copy section copies "Greeting" property value into the ReplySayHelloVar variable:

.....
<bpel:copy>
     <bpel:from xmlns:property="java:org.switchyard.component.bpel.riftsaw.SwitchYardPropertyFunction"
                expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0">
         <![CDATA[concat(property:resolveProperty('Greeting'), $ReceiveSayHelloVar.parameters/tns:input)]]>
     </bpel:from>
     <bpel:to part="parameters" variable="ReplySayHelloVar">
         <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[tns:result]]></bpel:query>
     </bpel:to>
</bpel:copy>

Injecting Implementation Properties in BPMN 2

TODO:

Injecting Implementation Properties in Drools

TODO:

Invocation properties

While it is a best practice to write your service logic to the data that is defined in the contract (the input and output message types), there can be situations where you need to access contextual information like message headers such as received file name in your implementation. To facilitate this, the Bean component allows you to access the SwitchYard Exchange Context instance associated with a given Bean Service Operation invocation. Invocation properties represent the contextual information (like message headers) in your bean implementation.

Accessing Invocation Properties

To enable access to the invocation properties, add a Context property to your bean and annotate it with the CDI @Inject annotation:

@Service(SimpleService.class)
public class SimpleServiceBean implements SimpleService {

@Inject
private Context context;

public String sayHello(String message) {
        System.out.println("*** Funky Context Property Value: " + context.getPropertyValue("funkyContextProperty"));
        return "Hi there!!";
    }
}

Here, the Context interface allows your bean logic to get and set properties in the context.

You can invoke the Context instance only within the scope of one of the Service Operation methods. If you invoke it outside this scope, it results in an UnsupportedOperationException error.

Domain properties

See package: org.switchyard.common.property

PropertyResolvers: PropertiesPropertyResolver TestPropertyResolver SystemAndTestPropertyResolver CompoundPropertyResolver MapPropertyResolver

Creating our custom propertyResolver and registering it in switchyard.xml in switchyard as propertyResolver. https://github.com/jboss-switchyard/core/blob/master/config/src/main/java/org/switchyard/config/DOMConfiguration.java#L685

Additional info

See: https://community.jboss.org/message/867080 https://community.jboss.org/message/819215 See: https://docs.jboss.org/author/display/SWITCHYARD/Properties

Tips and tricks

Define default value for a property

When we define a property, we can provide a default value, so if the property is not defined by the user it will get this default value. To define this default value, just append to the property name the default value, separated by a colon (:).

${server.port:8080}

Where to define environment properties

See: https://community.jboss.org/message/868913

As component properties

Properties can be defined as component property. This way of defining properties is not dynamic, but every properties defined here, can be overriden by properties defined in a "prioritized" scope.

<sy:switchyard ...>
  <sca:composite ...>
    <sca:component ...>
      ...
      <sca:property value="test" name="MY_PROPERTY"/>
    </sca:component>
    <sca:service...>
      ...
    </sca:service>
    <sca:reference ...>
      ...
    </sca:reference>

  </sca:composite>
  ...
</sy:switchyard>

As composite properties

Properties can be defined as composite property. This way of defining properties is not dynamic, but every properties defined here, can be overriden by properties defined in a "prioritized" scope.

<sy:switchyard ...>
  <sca:composite ...>
    <sca:component ...>
      ...
    </sca:component>
    <sca:service...>
      ...
    </sca:service>
    <sca:reference ...>
      <sca:interface.java .../>
      <file:binding.file name="FileBinding">
        <file:directory>/tmp</file:directory>
        <file:fileName>${MY_FILENAME}</file:fileName>
        <file:produce/>
      </file:binding.file>
    </sca:reference>
    <sca:property value="test.txt" name="MY_FILENAME"/>
  </sca:composite>
  ...
</sy:switchyard>

As domain properties

Properties can be defined as composite property. This way of defining properties is not dynamic, but every properties defined here, can be overriden by properties defined in a "prioritized" scope.

<sy:switchyard ...>
  <sca:composite ...>
    <sca:component ...>
      ...
    </sca:component>
    <sca:service...>
      ...
    </sca:service>
    <sca:reference ...>
      ...
    </sca:reference>
  </sca:composite>
  ...
  <sca:domain>
    <sca:property value="test.txt" name="MY_FILENAME"/>
  </sca:domain>
 </sy:switchyard>

In a static module (or dynamic)

Right now, it seems that defining properties in static module does not work. They do not get picked up by the property resolvers. Properties can be externalized from the SwitchYard application it self by defining them outside the switchyard.xml file. One place could be a module. For this to work, you need to define your module:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<module xmlns="urn:jboss:module:1.0" name="com.examples.switchyard.properties">
    <properties>
        <property name="ftp_server.host" value="localhost"/>
        <property name="ftp_server.port" value="22"/>
    </properties>
</module>

And use these properties in your SwitchYard application:

<ftp:binding.sftp>
    <ftp:host>${ftp_server.host}</ftp:host>
    <ftp:port>${ftp_server.port}</ftp:port>
   ....
</ftp:binding.sftp>

As OS environment properties

Properties can be loaded from OS environment properties. Every environment property is accesible by prefixing it with env.

So a property defined like (in bash):

export MY_PROPERTY=test

Can be used in your SwitchYard application:

<ftp:binding.sftp>
    <ftp:host>${env.MY_PROPERTY}</ftp:host>
   ....
</ftp:binding.sftp>

As Application Server properties from AS configuration

Application server has the ability to define properties directly in it’s configuration (either by file or with the console) and this configuration will be dynamically updated, and persisted. See: https://community.jboss.org/wiki/JBossAS7SystemProperties

Adding the following configuration to the definition of the server definition:

<server name="xyz.home" xmlns="urn:jboss:domain:1.0">
    <extensions>
        <extension module="org.jboss.as.clustering.infinispan"/>
        <extension module="org.jboss.as.clustering.jgroups"/>
        <extension module="org.jboss.as.connector"/>
        ....
    </extensions>
    <system-properties>
        <property name="MY_PROPERTY" value="test"/>
    </system-properties>

This properties will be used in the same way:

<ftp:binding.sftp>
    <ftp:host>${MY_PROPERTY}</ftp:host>
   ....
</ftp:binding.sftp>

As Application Server properties from file

You can pass a properties file as an argument to JBoss AS startup script, and it will load all the properties in the file and make then accesible, so we can start the AS like:

$./standalone.sh -P file:///data/production.properties

And this properties will be accesible, as in any other example above.

See: JBoss EAP command line switches

Provided alternatives are

-P=<url>	Load system properties from the given URL.
-P <url>	Load system properties from the given URL.
--properties=<url>	Load system properties from the given URL.

Using maven to set up your properties

Preferred approach to Switchyard multiple environment properties?

Load all properties from a file

It is not possible to load all the properties available in a file, so a JIRA has been created.

   <sca:properties file="ftp.properties"/>

Loading properties for test

In tests, properties can be added and resolved at the top level. There is a PropertyMixIn that eases working with properties:

   private PropertyMixIn pmi;

   ...
   pmi.set("test.property.name", "test");
   pmi.set("test.property.name", Integer.valueOf(100));
   ...
   pmi.get("test.property.name");
   ...

If you need, underlying access to the PropertyResolver for tests, where a MixIn is not applicable (Not Running With SwitchYardRunner), and to avoid having to set command line parameters, there is a TestPropertyResolver.INSTANCE that can be used in tests.

To put a property do:

TestPropertyResolver.INSTANCE.getMap().put("name","value");

This property will be set, and retrieved by any service when resolving that property.