TWS sendevent command
TWS 8.4 introduced support for event driven scheduling. This included functionality to take an action when specific events occurred in the TWS estate including support for non-TWS events and actions. Through the Tivoli Dynamic Workload Console (TDWC) – the TWS web console, events and their corresponding actions can be defined using various sources (e.g. TWS events, file events, etc.) and actions (e.g. send an e-mail, TWS submit, etc.).
Whilst this works well for these pre-defined events, how can you deal with applications that don’t sit so comfortably within TWS? For example, a bespoke home grown or third party application, which after it has finished processing, you want TWS to submit a job stream. This can be achieved using the TWS supplied sendevent command that is installed as part of the TWS Remote Command Line (CLI) component. The TWS remote CLI can be installed on any system with or without other TWS components. The TWS remote CLI is described here TWS 8.3 and higher Command Line Client and from TWS 8.4 includes the sendevent capability.
sendevent
There are two versions of sendevent available – one that is installed as a component part of the Fault Tolerant Agent (FTA) installation and another that is installed as part of the TWS remote CLI. There are some significant differences between the two sendevent versions and it is important to understand these differences before using them in any business critical situations.
The sendevent binary/command/executable supplied as part of the FTA installation is automatically configured to send events to the TWS event server, which by default executes on the MDM. If the MDM fails over to a backup MDM and the appropriate “conman switcheventprocessor” command is issued following the “conman switchmgr” command, the FTA version of sendevent will automatically send any future events to the backup MDM. This is because the events are sent through the TWS agent hierarchy.
However, the sendevent binary/command/executable installed as part of the TWS remote CLI is configured by default to send events to the TWS event server on the MDM. This is achieved by a hard coded reference in a configuration file and consequently, if the MDM fails over to a backup MDM along with the event server, events from the TWS remote CLI version will be cached until the MDM is reinstated. For business critical applications this is not an ideal situation.
Configuring sendevent
This section is only applicable to the TWS remote CLI version of sendevent.
The default settings for the TWS remote CLI version of sendevent are held in the file <TWS_remote_CLI_home>EIFsendeventeif.templ as shown below. The MDM on my TWS test system is hosted on the server ardbeg.scotchwhisky.local and this server is automatically substituted in the reference $TWS:EIFhost when sednevent is executed. The sendeventeif.templ file read, the $TWS:EIFxxx variables replaced with actual values and the results written to the file sendeventeif.conf in the same location. Any existing sendeventeif.conf file will be overwritten.
ServerLocation=$TWS:EIFhost ServerPort=$TWS:EIFport BufferEvents=YES BufEvtPath=$TWS:home/EIF/sendeventcache.dat BufEvtMaxSize=20480 MaxPacketSize=4000 BufferFlushRate=0 ConnectionMode=CO NO_UTF8_CONVERSION=YES TransportList=t1 t1Type=$TWS:TransportType t1Channels=t_ t_ServerLocation=$TWS:EIFhost t_Port=$TWS:EIFport t_SSLPort=$TWS:EIFSSLport t_SSLRequireClientAuthentication=YES t_SSLSecurityLevel=HIGH t_SSLFIPS=$TWS:SSL_FIPS t_SSLCertificate=$TWS:SSLCertificate t_SSLCertificatePrivateKey=$TWS:SSLCertificatePrivateKey t_SSLCertificateStashFile=$TWS:SSLCertificateStashFile t_SSLCACertificate=$TWS:SSLCACertificate t_SSLKeystore=$TWS:SSKeystore t_SSLKeystorePW=$TWS:SSLKeystorePW t_SSLCertLabel=$TWS:SSLCertLabel t_SSLKeystoreFormat=PEM t_SSLPathLib=$TWS:home/bin t_GSKITPath=$TWS:GSKITPath t_ICCOSSPath=$TWS:OSSPath t_ICCPath=$TWS:ICCPath |
Configuring an alternative event server
To support an alternative event server such as the event server on the backup MDM, the sendeventeif.templ file needs to be modified to include the required definitions for the backup MDM. In the example below the MDM server is hosted on ardbeg.scotchwhisky.local and the backup MDM hosted on laphroaig.scotchwhisky.local. As TWS will replace any references to $TWS:EIFhost as the MDM server host, the references should be modified to refer to explicit server names as shown in the example below. All of the required modifications to sendeventeif.templ are highlighted in red.
ServerLocation=$TWS:EIFhost ServerPort=$TWS:EIFport BufferEvents=YES BufEvtPath=$TWS:home/EIF/sendeventcache.dat BufEvtMaxSize=20480 MaxPacketSize=4000 BufferFlushRate=0 ConnectionMode=CO NO_UTF8_CONVERSION=YES TransportList=t1 t1Type=$TWS:TransportType t1Channels=t_,u_ t_ServerLocation=ardbeg.scotchwhisky.local t_Port=$TWS:EIFport t_SSLPort=$TWS:EIFSSLport t_SSLRequireClientAuthentication=YES t_SSLSecurityLevel=HIGH t_SSLFIPS=$TWS:SSL_FIPS t_SSLCertificate=$TWS:SSLCertificate t_SSLCertificatePrivateKey=$TWS:SSLCertificatePrivateKey t_SSLCertificateStashFile=$TWS:SSLCertificateStashFile t_SSLCACertificate=$TWS:SSLCACertificate t_SSLKeystore=$TWS:SSKeystore t_SSLKeystorePW=$TWS:SSLKeystorePW t_SSLCertLabel=$TWS:SSLCertLabel t_SSLKeystoreFormat=PEM t_SSLPathLib=$TWS:home/bin t_GSKITPath=$TWS:GSKITPath t_ICCOSSPath=$TWS:OSSPath t_ICCPath=$TWS:ICCPath u_ServerLocation=laphroaig.scotchwhisky.local u_Port=$TWS:EIFport u_SSLPort=$TWS:EIFSSLport u_SSLRequireClientAuthentication=YES u_SSLSecurityLevel=HIGH u_SSLFIPS=$TWS:SSL_FIPS u_SSLCertificate=$TWS:SSLCertificate u_SSLCertificatePrivateKey=$TWS:SSLCertificatePrivateKey u_SSLCertificateStashFile=$TWS:SSLCertificateStashFile u_SSLCACertificate=$TWS:SSLCACertificate u_SSLKeystore=$TWS:SSKeystore u_SSLKeystorePW=$TWS:SSLKeystorePW u_SSLCertLabel=$TWS:SSLCertLabel u_SSLKeystoreFormat=PEM u_SSLPathLib=$TWS:home/bin u_GSKITPath=$TWS:GSKITPath u_ICCOSSPath=$TWS:OSSPathu_ICCPath=$TWS:ICCPath |
The above modifications add a second “channel” that will be used in the event that the first “channel” is unavailable when sendevent is executed. After a number of retries (the default is 5 I believe) if the server defined on “channel t_” is still unavailable, the second channel defined by the “channel u_” will be used. If the server defined on “channel u_” is available, sendevent processing is complete. If the server is unavailable, the event will be cached to the cache file. The cached event will remain there until the next TWS remote CLI version of the sendevent is executed, at which point, if the server on either “channel” is available the events in the cache will be sent in a FIFO order, with the current event being sent last to maintain the chronological order of the events.
Hits: 166