Operations Management Within IBM B2BI (Sterling Integrator)

View Only

Operations Management Within IBM B2BI (Sterling Integrator)

By Tanvi Kakodkar posted Mon January 20, 2020 04:31 AM

Like

Originally updated on April 7, 2015 by VinceTkac

Operations Management Within IBM B2BI (Sterling Integrator)

Vince Tkac and Walter Vargas

1. Overview

There are a number of management and monitoring features available in the UI. These features are generally driven either via the database or via calls between the nodes through the Ops Server.

The SI architecture includes components for an operations server and application servers. The application servers (including adapter containers) runs all adapters and business processes. The operations server acts as a remote, HTTP based API to the system. The operations server allows an administrator to control various aspects of the system. These same commands are used from the UI to drive screens like the troubleshooter, softstop, log, cache and pool statistics.

This document will describe those commands as well tips on when to use them.

2. Uses

The ops command interfaces provides a number of advantages:

Available from command line.
Allows for the automation of tasks.
Can be used for automated system monitoring.
Often still works when the UI isn't available.
Gathers information from all system nodes at once.
2.1 Commands

The command are broken up into a number of large groupings related to management of cache, pool, schedule, logs, engine, adapter and stats.

The ops command is a public API into the running SI system. This is similar to what JMX provides in other systems.

Ops commands are signed and include a timestamp to prevent replay.

Each command group takes a set of parameters that is specific to that group.

2.2 Cache Commands

SI utilizes a least recently used (LRU) cache scheme. Caches are in memory. Cache sizes can be configured via the cacheManager set of property files. Cache limiting is done by number of entries not size of entry (a 1 meg map and a 10 meg map are treated the same).

The cache group of command offers a way to list, dump and clear caches remotely.

2.2.1 Parameters

All parameters are specified as -pparm=value on the command line. The only exception to this is the node_name parameter which is specified as -nname.

node_name - The name of the node to send the command (e.g. "node1").

cache_name - The name of a cache.

cache_key - The object name within a cache.

remove_key - The object name within a cache.

2.2.2 DUMPCACHE

Show the contents of the cache.

bin/opscmd.sh -nnode1 -cDUMPCACHE -pcache_name=UserCache

<cache>

 <entry cacheName="UserCache">

 <wrapper key="anon" next="siTestUser33" prev="null">com.sterlingcommerce.woodstock.security.User

username = anon

userkey = 1330963702905-206398918 </>

 <wrapper key="siTestUser33" next="admin" prev="anon">com.sterlingcommerce.woodstock.security.User

username = siTestUser33

userkey = 1331834086354--43252573 </>

 </entry>

</cache>

Optional: cache_name

2.2.3 REMOVECACHE and CLEARCACHE

Remove all entries from the cache. This is a good way to quickly recover some memory when the system is thrashing.

bin/opscmd.sh -nnode1 -cCLEARCACHE -pcache_name=UserCache

Optional: cache_name

2.2.4 REFRESHCACHE

Refresh each entry in the cache by reloading the entry from its source. This method is rarely used. When source data changes, it is best to remove the entry from the cache and allow the next caller to reload the entry if needed.

Required: cache_name

Optional cache_key, remove_key

2.3 Logs

The log group of command offers a way to list, retrieve, view and delete logs remotely. The logging level can also be adjusted without having to cycle the JVM.

2.3.1 Parameters

All parameters are specified as -pparm=value on the command line. The only exception to this is the node_name parameter which is specified as -nname.

node_name - The name of the node to send the command (e.g. "node1").

logger_name - The name of the logger object.

logger_level - The output level of the logger (e.g. "DEBUG", "ERROR", "ALL").

2.3.2 LISTLOGS

Returns a list of all log files known to the loggers on that node. Multiple nodes may share the same directory so not all log files in the logs directory will be listed.

2.3.3 LISTLOGGERS

Return a list of all available logger objects as defined in the log.properties set of files. Multiple nodes may share the same directory so not all log files in the logs directory will be listed. A logger object is the encapsulation of a name, log file, log level and various configuration parameters about the logger works.

2.3.4 GETLOGDATA

Returns a list of all log files known to the loggers on that node. Similar to LISTLOGS but includes the file size.

2.3.5 GETLOGGERDATA

Return a list of all available logger objects as defined in the log.properties set of files as well as the associated configuration for the logger object. This includes the name, log file, log level and interval (the interval is how many lines will be written to the log before a new log file is created).

<entry>

<name>wflogger</name>

<filename>/B2BI/install/logs/wf.log</filename>

<displayname>Log.WorkFlow</displayname>

<outfile size="2349">/B2BI/install/logs/wf.log.D20120316.T023310</outfile>

<level>ERROR</level>

<interval>100000</interval>

</entry>

2.3.6 GETOPSLOGGERDATA

Same as GETLOGGERDATA but returns the loggers associated with the OpsServer.

2.3.7 GETLOGGERFILENAME

Returns the filename associated with the specified logger.
Required: logger_name

2.3.8 GETLOGGERLEVEL

Returns the current log_level for the specified logger.

Required: logger_name

2.3.9 SETLOGGERLEVEL

Sets the current log_level for the specified logger to the specified level. This is a great way to enable logging when the UI isn't responsive.

bin/opscmd.sh -nnode1 -cSETLOGGERLEVEL -plogger_name=wflogger -plogger_level=DEBUG

Required: logger_name, logger_level

2.3.10 GETOPSLOGLEVEL

Same as GETLOGGERLEVEL but for the loggers associated with the OpsServer.

2.3.11 SETOPSLOGLEVEL

Same as SETLOGGERLEVEL but for the loggers associated with the OpsServer.

2.3.12 DELETELOG

Delete a log file from the log directory. If an absolute path is specified, it must be in the log directory. If a relative path is specified, it will be canonicalized and must be in the log directory.

Required: node_name, logger_file

2.3.13 LOG

Retrieve the content of a log file by name.

Optional: log_file

2.4 JDBC

The log group of command offers a way to list, retrieve, view and delete logs remotely. The logging level can also be adjusted without having to cycle the JVM.

2.4.1 Parameters

All parameters are specified as -pparm=value on the command line. The only exception to this is the node_name parameter which is specified as -nname.

node_name - The name of the node to send the command (e.g. "node1").

id - The name of the ???

2.4.2 GETJDBCTRACKINGINFO

Returns tracking and statistic data for each pool in the system. If connections are in use, a stack trace will be show indicating what code checked out the connection and how long the connection has been in use. Keep an eye on this list for connections that have been in use a long time as that may indicate a connection leak or locking issue.

bin/opscmd.sh -nnode1 -cGETJDBCTRACKINGINFO

 <ENTRY>

 <NAME>mysqlUIPool</NAME>

 <SIZE>1</SIZE>

 <REQUESTS>121</REQUESTS>

 <REQUESTWAIT>0</REQUESTWAIT>

 <LIFESPAN>0</LIFESPAN>

 <IDLETIMEOUT>86400000</IDLETIMEOUT>

 <HOUSEKEEPINGINTERVAL>3600000</HOUSEKEEPINGINTERVAL>

 <EXECUTETESTONRESERVE>true</EXECUTETESTONRESERVE>

 <TESTONRESERVEQUERY>SELECT PRODUCT_LABEL from SI_VERSION where PRODUCT_LABEL = ?</TESTONRESERVEQUERY>

 <TESTONRESERVEINTERVAL>60000</TESTONRESERVEINTERVAL>

 </ENTRY>

2.4.3 ENABLEJDBCTRACKING

Enables tracking of JDBC connections. This is the same functionality as the JDBC Monitor in the UI.

bin/opscmd.sh -nnode1 -cENABLEJDBCTRACKING

2.4.3.1 DISABLEJDBCTRACKING

Disable tracking of JDBC connections. This also clears the in-memory tracking data.

bin/opscmd.sh -nnode1 -cDISABLEJDBCTRACKING

2.4.4 SETJDBCTRACKING

Set the JDBC tracking level to the specified level. The same string mnemonics are available here for the tracking level as are available in the jdbc.properties file (FULL, LIGHTWEIGHT, NONE).

Required: id

2.4.5 REFRESHPOOLMAX

Send a signal to all nodes telling them to rescan the JDBC properties files for potential pool size changes.

2.4.6 REFRESHJDBC

Send a signal to all nodes telling them to rescan the JDBC properties files for potential pool size changes.

2.4.7 REFRESHPOOL

Required: poolName

2.5 Engine

2.5.1 Parameters

All parameters are specified as -pparm=value on the command line. The only exception to this is the node_name parameter which is specified as -nname.

node_name - The name of the node to send the command (e.g. "node1").

wf_id - The workflow ID.

timestamp - The timestamp as a long value.

description - The text description of why the action is being taken.

2.5.2 GETQUEUEDEPTH

Return a count of all jobs waiting to execute on the node. This is a sum of jobs across all queues on the node.

<QUEUEDEPTH_MESS>

<QUEUEDEPTH server="node1">3480</QUEUEDEPTH>

</QUEUEDEPTH_MESS>

2.5.3 GETALLQUEUEDEPTHS

Return a count of jobs waiting to execute on the node per queue.

<ALLQUEUEDEPTHS_MESS>

 <ALLQUEUEDEPTHS server="node1">

 <QUEUE_DEPTH queue="0">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="1">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="2">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="3">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="4">3322</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="5">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="6">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="7">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="8">0</QUEUE_DEPTH>

 <QUEUE_DEPTH queue="9">0</QUEUE_DEPTH>

 </ALLQUEUEDEPTHS>

</ALLQUEUEDEPTHS_MESS>

2.5.4 BROWSEQUEUE

Return a list of BPs waiting to execute on the node.

<QUEUEBROWSE_MESS>

 <QUEUEBROWSE>

 <qbrowse>

 <node>node1</node>

 <wfid>104115</wfid>

 <wfid>105446</wfid>

 <wfid>104116</wfid>

 <wfid>105447</wfid>

 <wfid>104117</wfid>

 <wfid>105448</wfid>

 </qbrowse>

 </QUEUEBROWSE>

</QUEUEBROWSE_MESS>

2.5.5 LISTQUEUEINFO

Not used for anything.

2.5.6 GETEXECSTATISTICS

Return average execution time for the queues.

<EXECSTATISTICS_MESS>

 <EXECSTATISTICS server="node1">

 <EXEC_TIME queue="0">0</EXEC_TIME>

 <EXEC_TIME queue="1">0</EXEC_TIME>

 <EXEC_TIME queue="2">0</EXEC_TIME>

 <EXEC_TIME queue="3">16</EXEC_TIME>

 <EXEC_TIME queue="4">5039</EXEC_TIME>

 <EXEC_TIME queue="5">0</EXEC_TIME>

 <EXEC_TIME queue="6">0</EXEC_TIME>

 <EXEC_TIME queue="7">0</EXEC_TIME>

 <EXEC_TIME queue="8">0</EXEC_TIME>

 <EXEC_TIME queue="9">0</EXEC_TIME>

 </EXECSTATISTICS>

</EXECSTATISTICS_MESS>

2.5.7 GETWAITSTATISTICS

Return average wait time for the queues.

<WAITSTATISTICS_MESS>

 <WAITSTATISTICS server="node1">

 <WAIT_TIME queue="0">0</WAIT_TIME>

 <WAIT_TIME queue="1">0</WAIT_TIME>

 <WAIT_TIME queue="2">0</WAIT_TIME>

 <WAIT_TIME queue="3">0</WAIT_TIME>

 <WAIT_TIME queue="4">0</WAIT_TIME>

 <WAIT_TIME queue="5">0</WAIT_TIME>

 <WAIT_TIME queue="6">0</WAIT_TIME>

 <WAIT_TIME queue="7">0</WAIT_TIME>

 <WAIT_TIME queue="8">0</WAIT_TIME>

 <WAIT_TIME queue="9">0</WAIT_TIME>

 </WAITSTATISTICS>

</WAITSTATISTICS_MESS>

2.5.8 GETQUEUECONFIGURATION

Return configuration information for the workflow ques. This information is configured via the workflow and noapp properties files.

<QUEUECONFIGURATION_MESS>

<QUEUECONFIGURATION server="node1">

<WORKFLOW_QUEUE_INFO>

<CONFIGURATION>

<MODE>MULTI_CLUSTER</MODE>

<QUEUE Priority="0">

<PRIORITY>0</PRIORITY><MAX_DEPTH>10000</MAX_DEPTH><MAX_THREADS>100</MAX_THREADS><THREADS>1</THREADS><AE_EXECUTE_CYCLE>1</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>10</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY>

</QUEUE>

<QUEUE Priority="1">

<PRIORITY>1</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>1</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>1000</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>0</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

…

<QUEUE Priority="9">

<PRIORITY>9</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>4</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>50</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>10</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

</CONFIGURATION>

</WORKFLOW_QUEUE_INFO>

</QUEUECONFIGURATION>

</QUEUECONFIGURATION_MESS>

2.5.9 GETCACHECONFIGURATION

Return configuration information for the workflow cache. This information is configured via the workflow and noapp properties files.

<CACHECONFIGURATION_MESS>

 <CACHECONFIGURATION server="node1">

 <WORKFLOW_CACHE_INFO>

 <CONFIGURATION>

 <USE_CACHE>true</USE_CACHE>

 <IN_MEMORY_CACHE>

 <SIZE>671088640</SIZE>

 <CONTEXT_SIZE>16384</CONTEXT_SIZE>

 </IN_MEMORY_CACHE>

 <DISK_CACHE>

 <SIZE_LIMIT>9223372036854775806</SIZE_LIMIT>

 <DELETE_THREADS>1</DELETE_THREADS>

 <SPREAD>1</SPREAD>

 <WRITE_THREADS>0</WRITE_THREADS>

 </DISK_CACHE>

 </CONFIGURATION>

 </WORKFLOW_CACHE_INFO>

 </CACHECONFIGURATION>

</CACHECONFIGURATION_MESS>

2.5.10 GETCACHEHISTOGRAM

Return data to populate a histogram showing a count of objects by size range which have been stored in the wofklow context cache.

<CACHEHISTOGRAM_MESS>

 <CACHEHISTOGRAM server="node1">

 <SIZE id="0" minsize="0" maxsize="2048">0</SIZE>

 <SIZE id="1" minsize="2048" maxsize="4096">3989</SIZE>

 <SIZE id="2" minsize="4096" maxsize="8192">4207</SIZE>

 <SIZE id="3" minsize="8192" maxsize="16384">6568</SIZE>

 <SIZE id="4" minsize="16384" maxsize="32032">0</SIZE>

 <SIZE id="5" minsize="32032" maxsize="65535">0</SIZE>

 <SIZE id="6" minsize="65535" maxsize="131072">0</SIZE>

 <SIZE id="7" minsize="131072" maxsize="262144">0</SIZE>

 <SIZE id="8" minsize="262144" maxsize="524288">0</SIZE>

 <SIZE id="9" minsize="524288" maxsize="2147483647">0</SIZE>

 </CACHEHISTOGRAM>

</CACHEHISTOGRAM_MESS>

2.5.11 GETCUMULATIVECACHESTATS

Return various workflow context cache statistics.

<CUMULATIVECACHESTATS_MESS>

 <CACHESTATS server="node1">

 <TOTAL_OPS id="0">14782</TOTAL_OPS>

 <EXEC_IMMEDIATE id="1">4203</EXEC_IMMEDIATE>

 <SOFT_REF_CACHE id="2">0</SOFT_REF_CACHE>

 <IN_MEMORY_CACHE id="3">9071</IN_MEMORY_CACHE>

 <DISK_CACHE id="4">0</DISK_CACHE>

 <SOFT_REF_SIZE id="5">0</SOFT_REF_SIZE>

 <IN_MEM_AVAILABLE id="6">650653236</IN_MEM_AVAILABLE>

 <IN_MEM_USED id="7">20435404</IN_MEM_USED>

 <DISK_AVAILABLE id="8">9223372036854775806</DISK_AVAILABLE>

 <DISK_USED id="9">0</DISK_USED>

 <SOFT_REF_AVAILABLE id="10">104857600</SOFT_REF_AVAILABLE>

 <SOFT_REF_USED id="11">0</SOFT_REF_USED>

 </CACHESTATS>

</CUMULATIVECACHESTATS_MESS>

2.5.12 LISTTHREADS

Return a list of active thread names on a particular node.

2.5.13 GETTHREADDATA

Return a list of active threads with jobs details for a particular node. This is the data used in the UI to show the thread info from the Troubleshooter page.

<list>

<entry>

 <name>HAR.110130.Thread</name>

 <priority>Queue:4 Priority:0</priority>

 <isAlive>true</isAlive>

 <isDaemon>true</isDaemon>

 <data>SleepService</data>

 <id>110130</id>

 <type>1</type>

 <time>1332789486403</time>

 <activityData>

 <key>molson:node1:13643784099:3172911</key>

 <complete>false</complete>

 <targetEnv>node1</targetEnv>

 <wfId>110130</wfId>

 <stepId>63</stepId>

 <SIIName>SleepService</SIIName>

 <SIIDisplayName>Sleep Service</SIIDisplayName>

 <SDIName>SleepService</SDIName>

 <startTime>1332789486403</startTime>

 <modTime>1332789491406</modTime>

 <progressData><percentComplete>50</percentComplete></progressData>

 </activityData>

 </entry>

</list>

2.5.14 STOPTHREAD

Use this command to interrupt or stop a thread in a running JVM. This is useful if a thread is stuck in an interruptible API call (such as sleep) or if the thread isn't responding and must be completely killed. Be caution about using KILL as it issues a Thread.stop() in java which can orphan JVM locks. After issuing a KILL, it is best to shutdown and restart the JVM.

Required: node_name, id, level ("KILL", "INT").

2.5.15 RESTARTWFS

2.5.16 SETINACTIVEWF
Use this command to mark a workflow as inactive. The workflow engine will stop executing the workflow at the next step. Different branches of the workflow may stop executing at different times as the steps complete. The workflow engine will keep this workflow ID marked as inactive.

Required: wf_id, timestamp, description

2.5.17 UNSETINACTIVEWF

Use this command to allow a workflow previously marked as inactive to run again.

Required: wf_id

2.5.18 EXPEDITEWF

Use this command to expedite completion of a particular workflow by moving it to the front of the queue.

Required: wf_id, timestamp (not used), description (not used)

2.5.19 REFRESHINACTIVEWFS

Use this command to re-read the list of inactive workflows from the DB.

2.5.20 GETQUEUEWATCHERINFO

Show workflow queue information.

%) bin/opscmd.sh -nnode1 -cGETQUEUEWATCHERINFO -pid=cluster

Cluster Multicast Information<

<{[{[Cluster Node Information for: node1]}{[NodeInfoNotificationBus toString() ]}

{[Sent:0 NotSent:0: Received:0]}

{[<{[ClusterID:00000001- 6a- 49 -71 3-9 65 5a 59 63 4d 4a 79 6a 7a 56 69 75 jiq9ezycmjyjzviu00000011 7a 4f 73 31 6e 45 46 42 79 70 6b 3d 0d 0a zos1nefbypk..]}{[NodeName:node1]}{[listenerPort:11760]}{[VMID:node1:11760]}{[addr:molson/10.30.2.165]}{[suspect:false]}{[unavailable:false]}{[BPExec:true]}{[nodeRole:]}{[load 0:0]}{[load 1:0]}{[load 2:0]}{[load 3:0]}{[load 4:5689]}{[load 5:0]}{[load 6:0]}{[load 7:0]}{[load 8:0]}{[load 9:0]}{[queueStatus 0:queueStatus[0]]}{[queueStatus 1:queueStatus[1]]}{[queueStatus 2:queueStatus[2]]}{[queueStatus 3:queueStatus[3]]}{[queueStatus 4:queueStatus[4]]}{[queueStatus 5:queueStatus[5]]}{[queueStatus 6:queueStatus[6]]}{[queueStatus 7:queueStatus[7]]}{[queueStatus 8:queueStatus[8]]}{[queueStatus 9:queueStatus[9]]}{[JGroupsAddr:10.30.2.165:11761]}>]}

{[-----------------NodeInfo Array--------------------

]}{[<>]}]}>>

tkac@molson 360 %) bin/opscmd.sh -nnode1 -cGETQUEUEWATCHERINFO -pid=stats

[SendOpsCommand], result of URL.fetch is

<SCHEDULINGPOLICY name="com.sterlingcommerce.woodstock.workflow.queue.FairShareSchedulingPolicy" <WORKFLOW_CACHE_INFO>

<CONFIGURATION>

<USE_CACHE>true</USE_CACHE>

<IN_MEMORY_CACHE><SIZE>671088640</SIZE><CONTEXT_SIZE>16384</CONTEXT_SIZE></IN_MEMORY_CACHE>

<DISK_CACHE><SIZE_LIMIT>9223372036854775806</SIZE_LIMIT><DELETE_THREADS>1</DELETE_THREADS><SPREAD>1</SPREAD><WRITE_THREADS>0</WRITE_THREADS></DISK_CACHE>

</CONFIGURATION>

</WORKFLOW_CACHE_INFO><WORKFLOW_QUEUE_INFO><CONFIGURATION><MODE>MULTI_CLUSTER</MODE>

<QUEUE Priority="0"><PRIORITY>0</PRIORITY><MAX_DEPTH>10000</MAX_DEPTH><MAX_THREADS>100</MAX_THREADS><THREADS>1</THREADS><AE_EXECUTE_CYCLE>1</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>10</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="1"><PRIORITY>1</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>1</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>1000</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>0</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="2"><PRIORITY>2</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>8</MAX_THREADS><THREADS>8</THREADS><AE_EXECUTE_CYCLE>2</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>10</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="3"><PRIORITY>3</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>8</MAX_THREADS><THREADS>8</THREADS><AE_EXECUTE_CYCLE>2</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>10</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="4"><PRIORITY>4</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>8</MAX_THREADS><THREADS>1</THREADS><AE_EXECUTE_CYCLE>100</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>20</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="5"><PRIORITY>5</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>16</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>100</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>30</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="6"><PRIORITY>6</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>8</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>10</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>50</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="7"><PRIORITY>7</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>16</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>5</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>50</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="8"><PRIORITY>8</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>16</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>2</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>100</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

<QUEUE Priority="9"><PRIORITY>9</PRIORITY><MAX_DEPTH>500000</MAX_DEPTH><MAX_THREADS>4</MAX_THREADS><THREADS>0</THREADS><AE_EXECUTE_CYCLE>50</AE_EXECUTE_CYCLE><CACHE_THRESHOLD>10</CACHE_THRESHOLD><JAVA_PRIORITY>5</JAVA_PRIORITY></QUEUE>

</CONFIGURATION>

</WORKFLOW_QUEUE_INFO>

<CONTEXT_CACHE_STATISTICS><UNITS>Bytes</UNITS>

<MIN>2853</MIN>

<MAX>14938</MAX>

<AVERAGE>3317</AVERAGE>

<HISTOGRAM segments="STATIC">

<SEGMENT id="0" min="0" max="2048">0</SEGMENT>

<SEGMENT id="1" min="2048" max="4096">3959</SEGMENT>

<SEGMENT id="2" min="4096" max="8192">4205</SEGMENT>

<SEGMENT id="3" min="8192" max="16384">6566</SEGMENT>

<SEGMENT id="4" min="16384" max="32768">0</SEGMENT>

<SEGMENT id="5" min="32768" max="65536">0</SEGMENT>

<SEGMENT id="6" min="65536" max="131072">0</SEGMENT>

<SEGMENT id="7" min="131072" max="262144">0</SEGMENT>

<SEGMENT id="8" min="262144" max="524288">0</SEGMENT>

<SEGMENT id="9" min="524288" max="9223372036854775807">0</SEGMENT>

<EVENTS>

 <NOCACHE>4203</NOCACHE>

 <CONTEXTOPS>14730</CONTEXTOPS>

 <MEMCACHE>5211</MEMCACHE>

</EVENTS>

</HISTOGRAM>

<SOFT_REF_SIZE>0</SOFT_REF_SIZE><IN_MEM_AVAILABLE>616695568</IN_MEM_AVAILABLE><IN_MEM_USED>54393072</IN_MEM_USED><DISK_AVAILABLE>9223372036854775806</DISK_AVAILABLE><DISK_USED>0</DISK_USED><SOFT_REF_AVAILABLE>104857600</SOFT_REF_AVAILABLE><SOFT_REF_USED>0</SOFT_REF_USED></CONTEXT_CACHE_STATISTICS>

Ok<EVENTCOUNTS/>

</SCHEDULINGPOLICY>

2.6 Softstop

2.6.1 MARKNODEUNAVAILABLE

Marks the node as available to allow other nodes to send workflows to this node.
```
Marking a node unavailable
```
```
    opscmd.sh -cMarkNodeUnavailable -pname=node_name
```

2.6.2 MARKNODEAVAILABLE

Marks the node as unavailable to prevent other nodes from sending workflows to this node.
```
Marking a node available
```
```
    opscmd.sh -cMarkNodeAvailable -pname=node_name
```

2.6.3 BLOCKQUEUE

Marks the queue as blocked. Once the queue is marked as blocked, no further jobs can be added to the queue. Jobs will either be sent to another node in the cluster or saved to the DB.

Block a queue or all queues

    opscmd.sh -cBlockQueue -pname=node_name -pid={queue_id | all} [ -pbpCompletionPolicy={1 | 2 | 3 } ]

    all means blocking all queues

  1  finish current step of the BP

  2  finish current execution cycle of the BP

  3  finish whole BP

2.6.4 UNBLOCKQUEUE

Makes the queue no longer appear as blocked. This allows normal operation of the queue again.
```
Unblock a queue or all queues
```
```
    opscmd.sh -cUnblockQueue -pname=node_name -pid={queue_id | all}
```

2.6.5 DRAINQUEUE

Drain a queue of jobs once the queue is blocked. Jobs are drained based on the bpDrainPolicy.

Drain a queue or all queues

    opscmd.sh -cDrainQueue -pname=node_name -pid={queue_id | all} [-pbpDrainPolicy={1 | 2 | 3 | 4}]

    Note: This is a asynchronous command, one needs to use next command to see the status of queue draining

   1   Drain all the BP in the queue.

   2   Drain all not started BPs in the queue

   3   Drain nothing

   4   Drain BPs that have not been started and without open session with adapters

2.6.6 GETDRAINQUEUESTATUS

See the status of queue draining

    opscmd.sh -cGetDrainQueueStatus -pname=node_name -pid={queue_id | all}

2.6.7 EXECUTEBPSONQUEUE

Execute any jobs remaining on the queue after the DRAINQUEUE command has completed.

Execute BPs on a queue or all queues

    opscmd.sh -cExecuteBPsOnQueue -pname=node_name -pid={queue_id | all} [-ptimeoutForQueues=timeout_out_in_seconds]

    Note: This is a asynchronous command, one needs to use next command to see the status of BP execution

2.6.8 GETEXECUTEBPSONQUEUESTATUS

See the status of BP queues exection

    opscmd.sh -cGetExecuteBPsOnQueueStatus -pname=node_name -pid={queue_id | all}

2.6.9 GETTRANSPORTSESSIONBPS

List all active BPs invoked by server adapters that have not sent back the BP result yet.

    opscmd.sh -cGETTRANSPORTSESSIONBPS [-pname=node_name] -pid={queue_id | all} -padapterNodeName=adapter_node_name

    Where adapter_node_name is the name of the node we are shutting down. If -pname is not specified, we will scan all ASI nodes

2.6.10 GETCLIENTSESSIONBPS

List all BPs that have not closed sessions with client adapters on the node we are shutting down.

    opscmd.sh -cGETCLIENTSESSIONBPS [-pname=node_name] -padapterNodeName=adapter_node_name

    Where adapter_node_name is the name of the node we are shutting down. If -pname is not specified, we will scan all ASI nodes

2.7 Adapters

2.7.1 LISTADAPTERS

List all adapters known to this node.

2.7.2 LISTACTIVEADAPTERS

List all adapters which are enabled for this node.

2.7.3 SERVERSTATUS

2.7.4 ADAPTERSTATUS

Show detailed status for each adapter.

bin/opscmd.sh -nnode1 -cADAPTERSTATUS

Required: name

Optional: id

<SII>

<servicename><![CDATA[TestHTTPServerAdapter-basicAuth]]></servicename>

<activestatus>1</activestatus>

<displayname><![CDATA[TestHTTPServerAdapter_basicAuth]]></displayname>

<systemservice>0</systemservice>

<targetenv><![CDATA[all]]></targetenv>

<adapterstatus>0</adapterstatus>

<adapterstatusmsg>No status detail available</adapterstatusmsg>

<parent><![CDATA[HttpServerAdapter]]></parent>

<licensed>true</licensed>

</SII>

2.7.5 GETADAPTERADVSTATE

Retrieve the detailed state information about an adapter. This includes when it started and stopped.

Required: name, id

<ADAPTERADVSTATE>

System Audit Information: 

2012-05-11 09:25:30.0 TestHTTPServerAdapter-basicAuth runtime state REGISTER_JNDI 

2012-03-15 13:19:11.0 TestHTTPServerAdapter-basicAuth runtime state RUNNING 

2012-03-15 12:28:02.0 TestHTTPServerAdapter-basicAuth runtime state REGISTER_JNDI 

2012-03-15 12:27:59.0 TestHTTPServerAdapter-basicAuth runtime state RUNNING 

Adapter Advanced State Information: 

Advanced state information for the adapter TestHTTPServerAdapter-basicAuth is not available. 

</ADAPTERADVSTATE>

2.7.6 STOPADAPTER

Use this command to stop an adapter by ID/name. This is a good way to shutdown an adapter from the commandline if the UI isn't responding.

The completeshutdown flag should be set to true when doing a two-step shutdown. The two-step shutdown is only used in the SWIFTNet adapter.

bin/opscmd.sh -nnode1 -cSTOPADAPTER -pid=MyAdapterName

Required: name, id

Optional: completeshutdown

2.7.7 STARTADAPTER

Use this command to start an adapter by ID/name on the specified node.

bin/opscmd.sh -nnode1 -cSTARTADAPTER -pid=MyAdapterName

Required: name, id

2.7.8 PREPARESTOPALLADAPTERS

Use this command to tell all adapters that a stop request is imminent. The adapter should stop accepting new requests but allow existing requests to complete. Not all adapters support this option fully. This is an important step when doing a shutdown so that in-process transfers are allowed to complete.

2.7.9 STOPALLADAPTERS

Use this command to tell all adapters to stop.

2.8 Locks

LISTINMEMLOCKS

LOCKNOTIFYALL

RELEASELOCK

2.9 JVM Stats

The ops layer provides for a number of JVM level statistics and reporting from the JVM's it monitors.

2.9.1 Parameters

node_name - The name of the node to send the command (e.g. "node1").

2.9.2 ISREADY

Indicator as to whether or not the node is ready. Set to true once the node has completed initialization during startup. This command is only used during startup.

2.9.3 PING

Uses the ISUP command (below) to determine if the node is available.

2.9.4 UPTIME

Returns the time, measured in milliseconds, between the current time and when the node was started.

2.9.5 MEMORY

Return the amount of memory, measured in bytes, used by the system and allocated to the heap.

2.9.6 ISUP

Connect to the ASI JVM via HTTP to determine if the system is available. Connects via the url property in noapp.properties.

2.9.7 SYSTEMSTATUS

Returns a consolidated set of data of the logging data, thread data and service/adapter data.

2.9.8 CACHESTATISTICS

Returns XML data showing a list of all caches in the system. The data includes the cache name, current size, number of requests to the cache and number of cache hits. This is a great way to gather and monitor cache effectiveness.

<CACHESTATISTICS>

 <ENTRY>

 <NAME>MapCache</NAME>

 <SIZE>10</SIZE>

 <REQUESTS>1234</REQUESTS>

 <HITS>700</HITS>

 </ENTRY>

 </CACHES>

</CACHESTATISTICS>

2.9.9 POOLSTATISTICS

Returns XML data showing a list of all pools in the system. The data includes the pool name, current size, number of requests to the pool, number of waits and pool configuration. This is a great way to gather and monitor pool effectiveness. The pools are configured via the jdbc.properties set of files.

<POOLS>

 <ENTRY>

 <NAME>mysqlPool_Select</NAME>

 <SIZE>1</SIZE>

 <REQUESTS>1</REQUESTS>

 <REQUESTWAIT>0</REQUESTWAIT>

 <LIFESPAN>0</LIFESPAN>

 <IDLETIMEOUT>86400000</IDLETIMEOUT>

 <HOUSEKEEPINGINTERVAL>3600000</HOUSEKEEPINGINTERVAL>

 <EXECUTETESTONRESERVE>true</EXECUTETESTONRESERVE>

 <TESTONRESERVEQUERY>SELECT PRODUCT_LABEL from SI_VERSION where PRODUCT_LABEL = ?</TESTONRESERVEQUERY>

 <TESTONRESERVEINTERVAL>60000</TESTONRESERVEINTERVAL>

 </ENTRY>

</POOLS>

2.9.10 CHECKJNDI

Connect to the ASI JVM via JNDI to determine if the system is available.

2.9.11 GETGISJVMSTATS

Retrieve consolidated statistics about the SI JVM. This includes memory use, thread count and connection count data.

2.9.12 GETSYSTEMTIME

Returns the system time as the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC

2.9.13 GETSERVERINFO

Returns data identifying the install directory, baseport, status of queue watcher, JVM vendor, JVM version and product version.

<SERVERINFO><LOCATION>/ais_local/share/tkac/gis_CATAMOUNT_BUILD_5020200_BRANCH_20120305/platform_core/install/noapp</LOCATION><BASEPORT>11700</BASEPORT><QWATCHER>false</QWATCHER><JVMVERSION>2.4</JVMVERSION><JVMVENDOR>Sun Microsystems Inc.</JVMVENDOR><NODEGISVERSION>6000</NODEGISVERSION></SERVERINFO>

2.10 Perimeter Server

REQUESTPERIMETERDUMP

SETPERIMETERCLIENTSTATUS

name=node2AC4&perimeterclient=junkperimeter&perimeterhost=localhost&

perimeterstatus=enable

LISTPERIMETERCLIENTS

perimeterClient, perimeterHost

<PERIMETER_SERVICES>

 <ENTRY>

 <NODE>node1</NODE>

 <NAME>local</NAME>

 <HOST>localhost</HOST>

 <PORT>0</PORT>

 <ISCONNECTED>true</ISCONNECTED>

 <ISENABLED>true</ISENABLED>

 <LASTCOMMUNICATION>1334079571151</LASTCOMMUNICATION>

 </ENTRY>

</PERIMETER_SERVICES>
2.11 Services

2.11.1 STOPSERVER

2.11.2 STARTSERVER

2.11.3 LISTSERVERS

2.12 Management Commands

2.12.1 RESTARTNICE

2.12.2 RESTART

2.12.3 SHUTDOWN

This command performs an automated graceful shutdown of a node. This command walks through all the graceful shutdown steps using timeouts.

Shut down a node or whole cluster

    opscmd.sh -cSHUTDOWN [-pname=node_name] [-pBPCompletionPolicy={1 | 2 | 3}] [-pBPDrainPolicy={1 | 2 | 3}] [-pTimeoutForQueues=time_out_in_seconds] [-pTimeoutForAdapters=time_out_in_seconds]

    Note: If a node is not specified, it is whole cluster shutdown.

2.12.4 STOPJVM

Stop a JVM by name.

    opscmd.sh -cSTOPJVM -pname=node_name

2.12.5 HARDSTOP

This command issues a System.exit(0) in the targeted environment. Use this command to shutdown a JVM after all services have been gracefully shutdown.

2.12.6 STOPOPS

This command allows the OpsServer to gracefully shutdown.

2.12.7 STOP

2.12.8 START

2.12.9 REFRESHNAMESPACES

This command performs a refresh of PrefixResolver. Use this command when a change is made to the namespace.properties file on disk.

2.12.10 LMREFRESH

This command performs a refresh of LicenseManager. Use this command when a new license is added to the DB and the JVM needs to re-read it.

2.13 Scheduler

2.13.1 RESETDEFAULTSCHEDENV

2.13.2 STARTSCHEDULES

2.13.3 STOPRESOURCEMONITOR

2.13.4 STARTSCHEDULESONFAILOVER

Move schedules off one node to another node.

    opscmd.sh -cStartSchedulesOnFailover -n{node_name} -pfailedNodeName={node_name}

2.13.5 STOPSCHEDULER

Move schedules to another node and stop the scheduler.

    opscmd.sh -cStopScheduler -pname={node_name} [-pFailoverNodeName={node_name}]

Note: If a failover node is not specified, we will pick one to move the schedules over if possible.

Note: This STOPSCHEDULER command sets a SoftStop flag on the node, which will prevent some system servicessuch as indexing and purge from running on that node again (even if the scheduler is restarted) until 
the node is recycled.

2.13.6 notifyNewScheduleByName

2.13.7 notifyNewScheduleById

2.13.8 notifyUpdateSchedule

2.13.9 notifyDeleteSchedule

The above four commands are implemented as extensions so the format is a little different.

Assuming the schedule is named "myScheduleName" and has ID "myScheduleID" and is running on "node1".

The command that gets passed into opscmd.sh via -c would be:

ext/schedule/notifyNewScheduleByName/myScheduleName/node1
ext/schedule/notifyNewScheduleByID/myScheduleID/node1
ext/schedule/notifyUpdateSchedule/myScheduleID/node1
ext/schedule/notifyDeleteSchedule/myScheduleID/node1

2.14 Misc

2.14.1 SETTUNINGPARAMS

2.14.2 GETTUNINGPARAMS

2.14.3 DELETEACTIVITYDATA

2.14.4 LISTLIVEINFO

tkac@molson 523 %) bin/opscmd.sh -nnode1 -cLISTLIVEINFO

Found internal config file /com/sterlingcommerce/security/jcae/provider.txt, loading it now!

Done loading it.

Controller loading lists...

[SendOpsCommand], result of URL.fetch is <?xml version="1.0" ?>

<LIVEDATA_MESS>

<THREADDATA_MESS>

<ServiceControllerData>

<activityData>

<key>36685213dcf12c5e8node1</key>

<complete>false</complete>

<targetEnv>node1</targetEnv>

<wfId>-2</wfId>

<SIIName>FTP_SERVER_ADAPTER</SIIName>

<SIIDisplayName>FTP Server Adapter</SIIDisplayName>

<SDIName>FtpServerAdapter</SDIName>

<activity>Session</activity>

<formatter>com.sterlingcommerce.woodstock.ui.svcmon.PipelineFormatter</formatter>

<startTime>1364997832230</startTime>

<modTime>1364997975669</modTime>

<contextData><start-time>2013-04-03 10:03:52.229</start-time> <session-id>FTP_SERVER_ADAPTER_13649978322254:6</session-id> <remote-address>9.55.52.214</remote-address></contextData>

<progressData><transport-security>none</transport-security> <state>Waiting for command.</state> <path>/<w/path> </progressData>

</activityData>

</ServiceControllerData>

<ServiceControllerData>

<activityData>

<key>83684513dcf12c5e8node1</key>

<complete>false</complete>

<targetEnv>node1</targetEnv>

<wfId>-2</wfId>

<SIIName>FTP_SERVER_ADAPTER</SIIName>

<SIIDisplayName>FTP Server Adapter</SIIDisplayName>

<SDIName>FtpServerAdapter</SDIName>

<activity>Session</activity>

<formatter>com.sterlingcommerce.woodstock.ui.svcmon.PipelineFormatter</formatter>

<startTime>1364997637413</startTime>

<modTime>1364997977961</modTime>

<contextData><start-time>2013-04-03 10:00:37.396</start-time> <session-id>FTP_SERVER_ADAPTER_13649976373111:3</session-id> <remote-address>127.0.0.1</remote-address></contextData>

<progressData><transport-security>none</transport-security> <state>Waiting for command.</state> <path>/</path> </progressData>

</activityData>

</ServiceControllerData>

</THREADDATA_MESS>

</LIVEDATA_MESS>

2.14.5 GETPERMNODEPROPERTIES

2.14.6 SETPERMNODEPROPERTIES

2.14.7 SETPERMLOGPROPERTIES

2.14.8 ADAPTERPROPERTIES

2.14.9 GETSERVICEINFO

2.14.10 GETSDIINFO

2.14.11 CONSOLIDATEDSTATUS

bin/opscmd.sh -nnode1 -cconsolidatedstatus -pdefaultInfo=false -plogInfo=true -pthreadInfo=false

2.14.12 REFRESHSDI

2.14.13 ADDUPDATESERVER

2.14.14 REFRESHSERVER

2.14.15 GETCONNECTIONSIZE

2.14.16 GETBINDINGS

2.14.17 REGISTER

2.14.18 GETSYSTEMMODE

2.14.19 GETSOFTSTOPSTATUS

2.14.20 UPDATESERVER

2.14.21 FIRENORMALEVENT

2.14.22 FIREABNORMALEVENT

2.14.23 LISTNICE

2.14.24 LISTNODESTATUSWITHSHUTDOWN

2.14.25 LISTNODEROLES

2.14.26 LISTNODESTATUS

2.14.27 UPDATECLUSTER

2.14.28 LIST

2.14.29 MESSAGE

2.14.30 PREREGISTER

#DataExchange
#IBMSterlingB2BIntegratorandIBMSterlingFileGatewayDevelopers

0 comments

170 views

IBM TechXchange Community

Together, we connect via forums, blogs,
files and face-to-face networking.

Sterling Managed File Transfer