Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 2 Creating a TIBCO Silver Fabric Enabler for Adapter for SAP Stack : Updating TIBCO Silver Fabric Enabler for Adapter for SAP Stack

Updating TIBCO Silver Fabric Enabler for Adapter for SAP Stack
When a stack is published and running, you can still make changes to the stack such as adding other components, changing allocation rules, changing threshold activation rules, or deploying and starting archives on the runtime Adapter for SAP Application instantiated on the engine.
Making changes to the stack is as easy as editing, saving, and publishing those changes to any instances that might be running. Some changes my require restart of the changed resource, so consult the TIBCO Silver Fabric documentation for best practices prior to making changes to a production system.
After making any changes to a stack, Save the changes and then from the Actions list in the main Stack page, select Publish Changes. The specified engines are affected by the changes immediately.
If you want to change an TIBCO® Adapter for SAP component, stop and restart your entire stack. To deploy, start, stop, and undeploy TIBCO® Adapter for SAP project archives, use the following ways:
Micro-scaling: Start and stop TIBCO® Adapter for SAP archives based on your defined rules when they are already in your component. For more information, refer to: Create Archive Scaling Rules
Continuous Deployment (deploy archives directly to Adapter for SAP endpoints) - publish (deploy), unpublish (undeploy), start, or stop Adapter for SAP archives without having to change any stacks, components, or Adapter for SAP Adapter for SAP engines. Deploying Adapter for SAP application archives via REST and cURL commands is described in the next section.
Deploying Archives Directly to Endpoints - Continuous Deployment
There are situations where deploying archives directly to a running TIBCO Adapter for SAP component can be useful, such as when an archive needs to be deployed and run on a system that is already running. This is known as continuous deployment. Archives can be directly deployed to Adapter for SAP instances already running on Silver Fabric Engines using the command line interface (CLI), Silver Fabric API, or an HTTP REST command sent using cURL or a Java client. Refer to the TIBCO Silver Fabric Cloud Administration Guide for more information on the CLI or the Silver Fabric API. Archive deployment, undeployment, starting, and stopping application archives via REST are described in further detail here.
TIBCO Silver Fabric supports many HTTP REST commands to GET, PUT, POST, and DELETE objects and managed resources for use with archive scaling, brokers, components, daemons, enablers, gridlibs, schedules, stacks, and Skyway.
 
TIBCO Silver Fabric REST Services are documented in the TIBCO Silver Fabric Administration Tool at Admin > REST Services. They are grouped by resource. Click any method name to see possible parameters if any and example responses.
Continuous deployment is discussed in good detail in the section on Deploying Archives Directly to Components in the TIBCO Silver Fabric Administration Guide.
The TIBCO Silver Fabric Enabler for Adapter for SAP adds more REST methods to enable control of Adapter for SAP archives.
Prior to using REST CLI with TIBCO Silver Fabric 5.6, you must change the Strict Validation setting. For the Configuration of the Broker make the General value as false..
Continuous Deployment Life Cycle
The continuous deployment life cycle has four REST operations that can be executed using cURL methods:
Deploy: Send an archive to a Silver Fabric Engine running an Adapter for SAP component that meets the criteria specified. The Deploy REST method enables specification of a properties files with criteria dictating where and how the archive should be deployed.
Start: Start an archive that was deployed to an engine.
Stop: Stop an archive that is running on an engine.
Undeploy: Remove an archive from an engine, stopping any running instances of that archive on that engine.
Deploy
Adapter for SAP application archives can be deployed directly to an appropriate Silver Fabric Engine (TIBCO Logical Machine) by calling the REST method. In this document cURL syntax is used to show REST inputs in a generic form:
curl -u UserName:Password \
-X POST \
-H "Accept:application/json" \
-H "Content-Type: multipart/form-data" \
-F "archiveFile=@YourArchiveName.zip" \
-F "deploymentFile=@YourDeploymentFileName.properties" \
[-F "LogicalAnd=false"]
-v "http://YourSFBroker.com:<port>/livecluster/rest/v1/sf/eng
ines/archives"
[-F "AppName=YourDirABC/YourAppName"]
[-F "AppSettings.element1.element2=SomeValue"]
[-F "ArchiveSettings.element1.element2=SomeValue"]
[-F "Archives=Archive_A,Archive_B,Archive_X"]
[-F "configurationFile=YourConfigurationfile.xml"]
[-F "ForceDeploy=true"]
[-F "GV=globalVariableA=123,globalVarB=SomeString"]
[-F "InstanceSettings.element1.element2=SomeValue"]
[-F "NoDeploy=true"]
[-F "NoStart=true"]
[-F "PUID=PUID_Value"]
[-F "VariableProvider=Some_PROVIDER_Name"]
 
Where inputs bounded by square brackets are optional; file names, elements, variable names, and any values shown in italics should be substituted by your implementation values.
 
Expressions in the generic form cURL expression are separated by line breaks to help with readability, but normally a string is submitted in the execution as in the following example:
Example 1 An example cURL archives deploy statement:
curl -u admin:admin -X POST -H "Accept:application/json" -H "Content-Type: multipart/form-data" -v http://MySFBroker.com:8080/livecl uster/rest/v1/sf/engines/archives -F "archiveFile=@MyProcessOrder.ear" -F "AppName=MyOrders/MyProcOrder" -F "deploymentFile=@MyDeplo yCriteria.properties"
Where the user specified by -u must have Silver Fabric administrator level permissions, and the form-data fields (-F "property=value") can be specified in any order. The form-data fields (-F) are described as follows:
Mandatory form-data contain the files necessary for the deployment:
archiveFile: specifies your Adapter for SAP archive file (.zip, .par, or .ear file) to upload to the Silver Fabric Broker which then publishes the archive to the appropriate Silver Fabric Engine. Multiple application archives can be deployed in a single archive ZIP or EAR file. You can deploy and run them all (default behavior) or you can selectively run a list of archives by specifying that list with the Archives form-data field. You can also upload archives using the Component Wizard.
deploymentFile: specifies the properties file that defines endpoint selection criteria described in more detail as follows:
-F "deploymentFile=@YourDeploymentFileName.properties"
LogicalAnd: (optional) by default all criteria specified in the deployment properties file must be satisfied for deployment to an application endpoint but that can be toggled to mean any (meaning logical OR) of the deployment properties criteria by setting: -F "LogicalAnd=false"
-v: specifies the target of the cURL POST execution and asks for a verbose response. The cURL -v expression should specify the appropriate Silver Fabric directory. For the default installation that expression looks like the following:
-v "http://YourSilverFabricBrokerName.com:<port>/livecluster/rest/ v1/sf/engines/archives"
Where the default http <port> is 8080 and optional form-data fields can specify other continuous deployment behavior.
AppName: specifies the directory location where the application archive(s) is deployed and what the application is named.
Where your archive application is deployed and what it is called depends on what you specify with AppName. For example when you use TIBCO Designer to create an .ear file with a name like MyAppArchive, varying the AppName specification gives following behavior:
• If the AppName form-data field is not specified, then MyAppArchive is deployed at the top level of the Administrator directory.
• If -F "AppName=A" is submitted in the curl request, then MyAppArchive is renamed to A and deployed at the top level.
• If -F "AppName=A/" is sent, then the directory folder A is used or created and MyAppArchive is deployed within that sub-directory.
• If -F "AppName=A/B" is sent, then the sub-directory A is used or created, and MyAppArchive is deployed there and renamed to B.
• If -F "AppName=A/B/" is sent, then the folder A with a sub-folder B is used or created and MyAppArchive is published within sub-folder B.
The full application name is derived from the AppName directory location and the application archive name as it is deployed.
Do not specify the optional form-data fields, unless you want to change the default behavior. By default all archives in the archive file are deployed and started unless an archive of the same name is already deployed and started, in which case that archive can run without interruption or replacement.
AppSettings: (optional) specifies settings that your application uses when deployed.
All deployment configuration cURL expressions take the form:
-F "AppSettings.element1.element2=SomeValue"
Some examples:
-F "AppSettings.localRepoInstance.encoding=UTF-8"
-F "AppSettings.description=This%20application%20deployment%20is%20fo
r%20validation%20testing."
 
Where the element is one of the following (plus any subordinate element2 where applicable):
a.
description: A string describing the application.
b.
contact: A string to name the person responsible for the deployment.
c.
maxDeploymentRevision: Specifies the default number of application revisions to keep in the revision history for each deployed application. Leave the value at -1 to keep all revisions by default.
d.
localRepoInstance: For enabler installed components and application archives installed with continuous deployment, a local file (or directory of files) is used as the deployment repository instance.
e.
encoding: Specifies encoding for the repository instance. If this element is not specified, then the encoding for the admin server is used. If the admin server is not available, then the default for this element is ISO8859-1.
Archives: (optional) form-data parameter that specifies a comma delimited list of archives within the zip that are to be deployed. If an archives list is omitted then all archives in the application archive package are deployed. Example:
-F "Archives=Archive_A,Archive_B,Archive_X"
ArchiveSettings: (optional) form-data parameter specifies settings for the archive.
a.
enabled: true or false. Only enabled services are deployed. Disabling a service, effectively undeploys just that service while letting all other services in the application run as normal. This can be useful when you wish to deploy an application that includes a service for which you don't have the required software. A deployment configuration cURL expressions takes the form:
-F "ArchiveSettings.enabled=true"
b.
av: Specify values for archive runtime variables with a comma-separated string with each key value pair joined by an equals (=) sign. For example:-
-F "ArchiveSettings.av=Deployment=T2.HTTP_GET-Tomcat,Domain=Mine"
Refer to the Appendix of the TIBCO Runtime Agent Scripting Deployment User’s Guide for a full list of Archive Settings properties, parameters, descriptions, and usage. Not all elements and properties are supported for use by the TIBCO ActiveMatrix® Adapter for SAP. The following is a first attempt at listing them all.
c.
hbInterval: heartbeat interval. The heartbeat interval determines the time (in milliseconds) between heartbeat messages.
d.
activationInterval: activation interval. This field specifies the amount of time to expire since the last heartbeat from the master before the secondary restarts the process starters and process engines.
e.
preparationDelay: preparation interval. This field is used to specify a delay before the master engine restarts.
f.
ruleBases: rule bases for the archive
ruleBase.uri: location of the rulebase file. Example syntax:
-F "ArchiveSettings.ruleBases.ruleBase.uri=someValue" ruleBase.data: Rulebase content. Do not change this setting.
g.
failureType: ANY, FIRST, SECOND, Subsequent
If event is used then Type must be specified.
Example syntax:
-F "ArchiveSettings.failureEvents.failureEvent.failureType=ANY"
restart: true or false. If true, the service instance is restarted upon failure.
description: information that describes this operation.
alertAction.performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
alertAction.enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called."
alertAction.level: High, Medium, Low
alertAction.message: The message that displays when this alert is triggered.
h.
performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
message: the message to send.
to: a comma-separated list of email addresses to which the message is sent.
cc: a comma-separated list of email addresses to which copies of the message are sent.
subject: the subject of the email message.
sMTPServer: The mail server (SMTP server) to use to send the message. Specify the host name or the host IP address.
i.
performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
command: specify the script to execute. Script files are highly recommended.
arguments: the list of arguments for the command.
j.
restart: true or false. If true, the service instance is restarted upon failure. description: information that describes this operation.
alertAction.performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
alertAction.enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
alertAction.level: High, Medium, Low
alertAction.message: The message that displays when this alert is triggered.
emailAction.performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
emailAction.enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
emailAction.message: the message to send.
emailAction.to: a comma-separated list of email addresses to which the message is sent.
emailAction.cc: a comma-separated list of email addresses to which copies of the message are sent.
emailAction.subject: the subject of the email message.
emailAction.sMTPServer: The mail server (SMTP server) to use to send the message. Specify the host name or the host IP address.
customAction.performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
customAction.enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
customAction.command: specify the script to execute. Script files are highly recommended.
customAction.arguments: the list of arguments for the command.
k.
restart: true or false. If true, the service instance is restarted upon failure.
Example syntax:
-F "ArchiveSettings.logEvents.logEvent.restart=true"
match: The string in the log file to match.
description: information that describes this operation.
alertAction.performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
alertAction.enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
alertAction.level: High, Medium, Low
alertAction.message: The message that displays when this alert is triggered.
emailAction.performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
emailAction.enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
emailAction.message: the message to send.
emailAction.to: a comma-separated list of email addresses to which the message is sent.
emailAction.cc: a comma-separated list of email addresses to which copies of the message are sent.
emailAction.subject: the subject of the email message.
emailAction.sMTPServer: The mail server (SMTP server) to use to send the message. Specify the host name or the host IP address.
customAction.performPolicy: the policy to perform. Once - Generates an alert only for the first occurrence. Always - Generates an alert for each occurrence.
customAction.enabled: true or false. If true, the action occurs when conditions for the action are true. If false, the action is not called.
customAction.command: specify the script to execute. Script files are highly recommended.
customAction.arguments: the list of arguments for the command
l.
failureCount: The value in this field defines how many restarts should be attempted before resetting the error counter to 0.
m.
failureInterval: The value in this field defines how much time should expire before resetting the error counter to 0.
InstanceSettings: (optional) Some syntax examples:
-F "InstanceSettings.initHeapSize=64
-F "InstanceSettings.maxHeapSize=512"
-F "InstanceSettings.threadStackSize=512"
a.
description: Specify any pertinent information about the binding.
b.
contact: Name the person responsible for this application instance.
c.
startOnBoot: When true the service instance starts when the computer is restarted. Default value is false.
d.
enableVerbose: When true, sets the enabler for verbose tracking for service instances. Default value is false.
e.
maxLogFileSize: Sets the maximum size (in kilobytes) that a log file can reach before the engine switches to the next log file.
f.
maxLogFileCount: Specifies the maximum number of log files to use. When the maximum number of log files have been written, the engine begins writing to the first log file again.
g.
threadCount: Specifies the number of threads to use to execute process instances. The number of threads determines how many process instances can execute concurrently.
h.
prepandClassPath: The values supplied here are prepended to your CLASSPATH environment variable.
i.
appendClassPath: The items you supply here are appended to your CLASSPATH environment variable.
j.
initHeapSize: Specifies the initial size (in MB) for the JVM used for the process engine. Default is 32 MB.
k.
maxHeapSize: Specifies the maximum size (in MB) for the JVM used for the process engine. Default is 256 MB.
l.
threadStackSize: Specifies the size of the thread stack. Default is 256 KB.
m.
runAsNT: When set to true the service is run as a Microsoft Windows Service. You can then manage the engine as you would any other service, and you can specify that it starts automatically when the machine reboots.
n.
startUpType: Specifies the instance service startup type as either: Automatic, Manual, or Disabled.
o.
login: Specifies the login account for the service, if any. The domain name must be specified as well.
p.
password: Sets the password for that service, if any.
q.
checkpoint: When set to true, the process engine waits for all jobs to finish (up to the maximum timeout) before shutting down the engine, rather than removing jobs at their next checkpoint.
r.
timeout: The maximum timeout in seconds the process engine waits for jobs to finish before shutting down the engine. A zero (0) value means 0 seconds, which effectively turns the graceful shutdown into an immediate shutdown.
s.
iv: This element uses a comma-separated string with name-value pairs with each key value pair joined by an equals (=) sign. For example:
configurationFile - (optional) form-data parameter used to include an XML configuration file created to modify archive properties if needed. Example syntax:
-F "configurationFile=YourConfigurationfile.xml"
Where your XML configuration file must use the same format as an enabler or component level configure.xml file with the outermost XML element as follows:
<archiveConfig name="YourArchiveName">
...
</archiveConfig>
For more information on writing an archive configuration file, see the "Using the Silver Fabric SDK" chapter of the TIBCO Silver Fabric Enabler for Adapter forSAP Developer’s Guide.
ForceDeploy: (optional) redeploy, forces a stop and overwrite of a pre-existing archive or set of archives with the same name. By default ForceDeploy is set to false and so a second deployment does not overwrite a pre-existing deployment of the same name. If there is a change of the archive file then ForceDeploy must be set to true so that the new application archive is redeployed. If ForceDeploy is used with -F Archives specifying a comma delimited list, then only those archives are stopped, undeployed, and redeployed.
-F "ForceDeploy=true"
GV: (optional) sets global variables for use on the targeted application endpoint by the archive. The GV form-data field lets you define a comma delimited list of declarative name equals value statements.
-F "GV=globalVariableA=123,globalVarB=SomeString"
For example to change the JMS SSL and Rv Service ports:
-F "GV=JmsSslProviderUrl=ssl://localhost:7555,RvService=7222"
If global variables are not defined with explicit values in the cURL statement then those values that you have set in the deployment configurationFile.xml are applied.
If global variables with the same name are set by both REST statement and a specified variable provider then the value set by REST statement overwrites and takes precedence over the value set in the variable provider.
VariableProvider: (optional) Specifies a variable provider to set global variables for applications deployed with REST. The variable provider is a Java Class extension compiled into a JAR and loaded into a Silver Fabric directory with an appropriate XML so that it can be called by REST during application deployment.
-F "VariableProvider=Some_PROVIDER_Name"
 
2. Export a JAR from it and save it to the TIBCO Silver Fabric Broker directory: SILVERFABRIC_HOME/webapps/livecluster/deploy/config/variableProvid ers
NoDeploy: (optional) default value is false which means that the archive(s) are uploaded to the Silver Fabric Broker and they are deployed to the application endpoints. When NoDeploy is set to true, the archives are uploaded with associated service enabler bindings created in TIBCO Administrator, but the archives are not deployed to a Silver Fabric Engine and the application endpoint.
-F "NoDeploy=true"
NoStart: (optional) default value is false, meaning that the archives are both deployed and started by default. If NoStart is set to true, the application is deployed but not started.
-F "NoStart=true"
Deployment File
When deploying an archive by REST you must include a deployment file, which specifies at least one selection criteria for determining which engine and component receives 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"
Statistic(name)
DependencyEngine(componentName)
Comparator: Valid comparators include =, !=, >, <, <=, >=, matches, contains, !matches, and !contains.
Example Deployment File
# Sample deployment file
ComponentType = "TIBCO ActiveMatrix Adapter for SAP:2.0.0"
Statistic(CPU Utilization) < 80
ActivationInfoProperty(ClusterName) matches dev_cluster.*
Successful Deployment
REST returns 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
}
The Engine-Id, Engine-Instance, and the full ArchiveName invokes of START, STOP, and UNDEPLOY methods to enable full control of the Archive life cycle.
An unsuccessful deployment returns an error of Status 500 or some other appropriate error status depending on the cause.
Continuous Deployment Timeout
Continuous deployment transfers can timeout due to one or more of the
following factors:
If you are encountering timeout issues, you can set a higher socket timeout between the Broker and engines. This can be set in the Silver Fabric Administration Tool at Config > Broker > Communications under the section HTTP Connections > Engines. The Socket Timeout parameter configures the HTTP connections established from Brokers to Clients and engines. Set the timeout value to the longest of the following three:
Start
Using REST you can also start application archives that were deployed but not started. You must know the Engine-Id, Engine-Instance, and the full application ArchiveName.
Example 2 Here is a generic cURL example that starts an Archive.
curl -u UserName:Password \
-X POST \
-H "Accept:application/json" \
-H "Content-type: multipart/form-data" \
-v "http://<YourSFBroker.com>:<port>/livecluster/rest/v1/sf/e
ngines/{engine-id}/{engine-instance}/archives/{full_archive-name}/
{archive-id}/start"
Expressions in the generic form cURL expression are separated by line breaks to help with readability, but normally an unbroken string is submitted in the execution as in the example shown in the tip.
Obtain the values of {engine-id} and {engine-instance} from the response to the successful cURL deployment REST execution or the TIBCO Silver Fabric Administrator > Engines page > expanding the row to see engine details.
There are also Silver Fabric REST methods to GET the engine-id and engine-instance for all instances running on a daemon. Refer to TIBCO Silver Fabric REST Services documented in the TIBCO Silver Fabric Administration Tool at Admin > REST Services.
The {full_archive-name} can be copied from the TIBCO Silver Fabric
Administrator > Dashboard > Scaled Archives page.
 
The {full_archive-name} must be URL-encoded in a cURL statement so that spaces are converted to "%20" and forward slashes "/" are represented by "%2F". Likewise other special characters must be encoded in appropriately.
engines/4649861604167227205/1/archives/%2FSilver%20Fabric%2FSFFL%2
Stop
You can stop application archives that are running on an engine by REST method by submitting a cURL expression to the Silver Fabric Broker. You must know the Engine-Id, Engine-Instance, and the full application ArchiveName.
curl -u UserName:Password
-X POST
-H "Accept:application/json"
-H "Content-type: multipart/form-data" \
-v "http://<YourSFBroker.com>:<port>/livecluster/rest/v1/sf/e ngines/{engine-id}/{engine-instance}/archives/{full_archive-name}/{archive-id}/stop"
Refer to the Start method for a description on how to obtain the values of {engine-id}, {engine-instance}, and {full_archive-name}.
Undeploy
You can undeploy application archives that are running on an engine by REST method by submitting a cURL expression to the Silver Fabric Broker. You must know the Engine-Id, Engine-Instance, and the full application ArchiveName.
curl -u UserName:Password
-X POST
-H "Accept:application/json"
-H "Content-type: multipart/form-data" \
-v http://<YourSFBroker.com>:<port>/livecluster/rest/v1/sf/e
ngines/{engine-id}/{engine-instance}/archives/{full_archive-name}/{archive-id}/undeploy"
-F "DeleteApp=true"
Refer to the Start method for a description on how to obtain the values of {engine-id}, {engine-instance}, and {full_archive-name}.
DeleteApp: (optional - for use with undeploy only) The default value is false and it can be omitted. When the DeleteApp parameter is false then an undeploy archive action leaves the application configurations of global variables and bindings so that they can be used again. The archive and the application are only undeployed and not deleted.
Setting DeleteApp to true deletes the application and the associated variable settings from the runtime engine after the archive is undeployed.
The Archive Management Support Feature
When components are activated, by default all archives are deployed and started in order. This behavior can be changed by editing the component in the component wizard, and editing the Archive Management Support feature. The Archive Management feature has an option that can be cleared to prevent archives from starting when the component is activated.

Copyright © TIBCO Software Inc. All Rights Reserved