We do a lot of these actions based on what we call a temp command, where we use a display only field (temp_command) and set come kind of value to the field, like SET_STATUS, and then have a filter that runs where the 'temp_command' = "SET_STATUS" do the real work, then have a piece of Perl or java code set the display only field. We use a field with the same Field ID for the display only field on all of our forms where we want to do this kind of temp command trigger and have the form name and value passed as command line parameters so we can have one Perl script work on many different forms. We will call this script in an escalation to get the filter processing off the escalation threads and onto fast threads. You could even have your script use private queues if you wanted to isolate the activity away from users.
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Ron Tavares Sent: Tuesday, June 19, 2012 7:08 AM To: [email protected] Subject: Re: Configuring a Solaris 10 server to run as an Escalation server - Pointers Needed ** Hi Vamsi, I am liking option 1 below which you and Fredrick suggested. I am not a java or perl guy, but I'm sure I could find one here to work with. Question on this; the escalations that are firing are basically setting a flag field, (which in some cases is just the status field). That flag field change then triggers Filter workflow that does all the real work. (typical Escalation stuff). My question is; is it enough to have the java/Perl code simply set the flag and let the Filters continue to do the work in Remedy? Or is the benefit only realized if we transfer ALL the real 'Work' to the java/perl code? Option 2; I also like this idea. There is a lot of OOTB workflow that fires on push to CTM:People, and I may not need all that to fire for what I am doing. (Maybe, mabye not). I will need to analyse this closer. Thanks, .ron On Thu, Jun 14, 2012 at 12:05 PM, patchsk <[email protected]<mailto:[email protected]>> wrote: ** Ron, Remedy has escalations feature to support recurring tasks, it can be used to certain extent for bulk or mass updates. But the tool is not very scalable if you are talking about very bulky jobs or too many recurring jobs. Though I have not seen many people reaching to this extreme but every company is different on how they use remedy. So the idea is offload them from escalations as much as possible and still be compatible with remedy workings. Here are a few things I can think of: 1. As Frederick mentioned you can create some java or perl programs using remedy apis. Embed them in a shell script and call those shell scripts using cronjobs or job scheduling tools. Since you are going through remedy api all the serverside workflow will still be triggered and all the validations and push fields will be perfomed. Prefer Java/C as there isn't any active support for ARS Perl. In this way though all the load is still be taken care by arserver, esclation has nothing to do with this. You can build as many arservers as you want and have these scripts connect to different arservers. So this can be very scalable. Also Remedy ITSM OOTB ignores indexes at several places so analyze where the lag is and try to create indexes where possible. 2. Another thing you can look into is, use the current mechanism you are doing, and where ever possible and you do not need any workflow to be triggered during escalation updates, create a filter with RunIF: $USER$ = "AR Escalator" and Action:GoTo 999. This will skip all the workflow during escalation runs. 3. You are correct, any updates directly at SQL level will not fire remedy workflow and will be significantly faster as you are removing the whole application layer. But BMC standing is you will loose the support if you directly touch the data. So use it as a last resort and check with them before hand. On Thursday, June 14, 2012 4:02:02 AM UTC-7, Ron Tavares wrote: ** Hi Vamsi Yes, BMC does raise concern in regards to the mixed OS. But they have not yet told us that is not supported. I agree that it would be best to be on the same OS. If we get good results with running escalations on Solaris, the plan is to eventually move all our ARs to Solaris. Yes, we are using escalation pools. We plan on extending escalation pools to some of the out of box escalations as well, once we confirm the Solaris box can handle the extra workload. The idea of using cronjobs is interesting. I'm assuming you are talking about cronjobs that would run some SQL scripts that would do the work of the Escalations/Filters? I imagine we could get better processing times out of this. However, I'm also thinking that this would prevent necessary subsequent workflow from firing. For example, when you perform a Push Filed to CTM:People, there is extensive out-of-box workflow that fires and updates a bunch of related records. Pushing values to CTM:People via a SQL action would not fire this workflow, correct? My guess is that it wouldn't but I could be wrong as I never tried it. .ron On Thu, Jun 14, 2012 at 2:13 AM, patchsk <[email protected]<mailto:[email protected]>> wrote: ** The cleanest way you can do this is by using server group feature, from your description it seems you are already using that feature. I have worked on Windows,Solaris , Linux environments. But your scenario is tricky, as you are mixing windows arservers with solaris arserver. I have not seen in the manuals/white papers or haven't heard before people attempting to create server groups with remedy servers on different OS. There isn't anything very sticky OS related stuff stored in Remedy Metadata, so it may even work, but I am not sure. Did you guys check with BMC if this even possible? I think the best practice is to have all servers in the group to be of same OS and Remedy Version/patch. Are you using escalation pools? It will increase the throughput as with pools multiple escalations can run parallel. Also corporates usually will have some job scheduling tools like BMC ControlM. See if you can convert some of the escalations into cronjobs or some kind of jobs. On Wednesday, June 13, 2012 5:26:02 AM UTC-7, Ron Tavares wrote: ** Good Morning Listers, The Problem: We have lots of escalation traffic running on our system, which causes our current Windows Escalation server to be over-taxed. To the best of my knowledge, there is no way to run escalations on more than one server at any given time. Solution Attempted: So, we are in the process of standing up and configuring a new AR server on Solaris 10, hoping that this will have more horsepower to handle the large traffic. But we are having some issues. First off, we are not seeing the increase in processing time that we had hoped for. We are also seeing various errors show up whenever escalations fire workflow that touches the CTM:People form. It's important to note that these do not show in the arerror.log, but rather they appear in the Putty session that was used to start the AR Server process. Examples of errors are as follows: Error signaling server <server name> Message number : 91 Message : RPC call failed Appended : RPC: Unable to receive; An event requires attention Status Struct : Message type : ERROR Error signaling server <server name> Status List : 1 items in thread "Status List : 1 items Message number : 90 main Message : Cannot establish a network connection to the AR System server " Appended : <server name>: RPC: Success Message : RPC call failed java.lang.NoClassDefFoundError: http://localhost:8080/rkm/fromRemedy/jsp?reset=remedyUsers Message type : ERROR There are other issues as well, such as the ARDBC Plugin appearing to load repeatedly every 10 minutes or so, after the AR Server starts. We have tried increasing and decreasing the List and Fast threads. The Escalations that we are testing are running on dedicated pools, and we have added the necessary threads to support those pools. The server does not show that it is being maxed out on memory or CPUs. Bottom Line: I think we just do not have this Solaris box configured correctly for Remedy. Perhaps we are approaching this with a "Windows" mentality and missing some key steps. So, my question is; is there anyone out there that is knowledgeable in configuring AR Servers on Solaris, and/or has seen these issues before. I could really use some pointers here as I am trying to guide the customer in the right direction, with my limited experience/knowledge in UNIX environments. Here are our specs: ARS 7.1 p11 ITSM 7.0 DB Oracle10 running on Solaris 10 All AR Servers are running on Windows Server 2003, (with the exception of the new Escalation server which is running on Solaris 10) We have a dedicated AR Server for Administrator functions and a dedicated server for Escalations. Thanking all you Solaris Gurus in Advance, Ron _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
