Deployment File
When deploying an archive by REST you must include a deployment file, which will specify at least one selection criteria for determining which Engine and Component will receive the deployed archive.
The deployment file is a simple properties text file specified by a form-data field like the following for REST upload with the archive:
-F "deploymentFile=@YourDeploymentFileName.properties"
The deployment file contains one or more logical statements with a criteria, a comparator, and a value, delimited by spaces:
criteria comparator value
Some criteria require an argument to be specified in parentheses:
criteria(argument) comparator value
For example, the following is a simple statement to deploy an archive to an Engine running a Component with a Component Type that contains Adapter as part of the name and which has a Domain name of YourDomain:
ComponentType contains Adapter ImportedVariable(TIBCO_DOMAIN_NAME) = YourDomain
By default all deployment file criteria statements must be satisfied for the deployment to occur, but you can change how the properties file criteria are evaluated to make them logical OR statements by using the optional cURL form-data switch: -F "LogicalAnd=false"
Criteria - The following criteria are supported:
- Comparator
- Valid comparators include =, !=, >, <, <=, >=, matches, contains, !matches, and !contains.
Example Deployment File
# Sample deployment file ComponentType = "TIBCO ActiveMatrix Adapter for Files:2.5.0" Statistic(CPU Utilization) < 80 ActivationInfoProperty(ClusterName) matches dev_cluster.*
Successful Deployment
REST will return a Status of 200 (OK) when the archive is successfully deployed. A successful REST execution returns the Engine-Instance and Engine-Id where the archive deployed. Example response (application/JSON):
{
"result": {
"name": "Archive Deployment",
"value": {
"message": "ENGINE '[1885509966828815621-5 : my_archive.ear]' DEPLOYED",
"Engine-Instance": "5",
"Engine-Id": "1885509966828815621"
}
},
"status": 200
}
Knowing the Engine-Id, Engine-Instance, and the full ArchiveName allows for invocation of START, STOP, and UNDEPLOY methods to enable full control of the Archive life cycle.
An unsuccessful deployment will return an error of Status 500 or some other appropriate error status depending on the cause.
1. Create a class that extends com.datasynapse.fabric.broker.userartifact.variable.AbstractVariableProvider and override the methods as needed. For example
package com.tibco.sf.providers;
import java.util.Properties;
import com.datasynapse.fabric.broker.userartifact.variable.AbstractVariableProvider;
public class My_Var_Provider extends AbstractVariableProvider
{
private static final long serialVersionUID = 1L;
@Override
public Properties getVariables()
{
Properties p = new Properties();
p.setProperty("MyApp/vars/name", "SomeString");
p.setProperty("MyApp/vars/episodic", "true");
p.setProperty("MyApp/vars/Xduration", "60");
return p;
}
@Override
public void destroy()
{}
@Override
public void init() throws Exception
{}
}
2. Export a JAR from it and save it to the TIBCO Silver Fabric Broker directory:
SILVERFABRIC_HOME/webapps/livecluster/deploy/config/variableProviders
3. Create an XML file with the properties shown below to associate the new class for TIBCO Silver Fabric.
<variableProvider class="com.tibco.sf.providers.My_Var_Provider"> <property name="name" value="Some_PROVIDER_Name"/> <property name="description" value="GV values are in the JAR"/> <property name="enabled" value="true"/> </variableProvider>
The variable provider name used by the REST statement is specified as "name" in the XML file.
4. Save the XML file in the same directory as the JAR:
SILVERFABRIC_HOME/webapps/livecluster/deploy/config/variableProviders
You can verify what variable providers are ready for use by REST invocation on the TIBCO Silver Fabric Administrator > Admin > Variables page.