Hello all,

During the SAP backup and downtimes, we have decided to write a script to disable the wM SAP Listeners before the downtime and later enable after the SAP is brought back.

Since this script needs to be provided to the SAP team, who have limited access to wM box, we have decided to provide a FTP script that triggers a service in WM box to enable/disable the listener.

Is there any other alternative that can be used for the same. Also do anyone see any issue with this approach.

Note: We are making use of the FTP gateway feature of WM for this
Thanks
Bhavani Shankar

I am just wondering what’s the need to disable the listener when SAP is down? Your approach to disable/enable via the virtual FTP functionality in WM IS seems ok.

Whenever SAP goes down, the listener keeps trying to connect and the number of threads reaches a maximum and the connection becomes stale.

Also the transactions go to the Status “Failed”

When the listener is disabled, the connection threads do not reach the threshold and also the queue of the listener maintians the transactions and clears them automatically once the listener is enabled.

Appreciate if anyone has seen any different behaviour than this.

Hope this clarifies
Bhavani Shankar

One need not share the Unix box credentials, as the FTP requires a wm user id with limited access only to invoke a service

the script is independent of Unix/Solaris/etc… as this invovles standard FTP commands.

Rest all the customization can be in the flow service which can also track the start and stop of the listerner.

Feel free to add more advantages of this approach !

BS

we are also working on SAP.

we are also working on SAP.

Bash,
If the downtime timeframe is known, you could probably use the webMethods service that is used to enable and disable the listener and schedule it to activate and deactivate the listeners.
i know the downtime thing i said is pretty unlikely.

Also you could ping the listener to see if its up( on a regular basis)…if it has been down (i.e no response from the listener for an x # of time)… you could disable the listener to stop it from trying too much and running out of maximum # of thread.

I hope i understand the scenario my two cents help.

-scoobydoo

smy,
Good job.
Lets us know if we can help if you ever hit a roadblock.

Hello,

the requirements of the solution is to have an approach that is triggerable from SAP or from outside of webMethods.

Reason: SAP Downtime are of 2 types, planned maintenance, emergency. above approach handles both of them.

Pinging is more of a post mortem. The listener is disabled after the SAP connection has gone down.

Scheduling works only for Planned maintenance only.

Thanks for your inputs.
Bhavani Shankar

Bash,

I overlooked the fact that this needs to be done from a non-webMethods source.

You are right about the downtime time frame and pinging.

Kick-starting the service through FTP would be a better more robust, reliable and “considerably” better approach.

Thanks for enlightening us.

Scoobydoo

happy to see some validation. that was nice. this approach is scalable to other adapters too, if we have an API to enable/disable.

thanks again.
BS

True, i have seen instances where connections are stale and the connection remains broken even after Sap comes up.

Are you referring to Transactions in Sap, or in IS. Transactions from IS to SAP has nothing to do with the listener(they go through through Sap Adapter Connection). Transactions coming from Sap to IS are not of interest, as Sap will be down anyway. May be i am missing something?

The queue of the listener is on the Sap side. So, when Sap is down, where does this queue get data from?