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 <vamsi...@gmail.com> 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 <vamsi...@gmail.com> 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/**from** >>>> Remedy/jsp?reset=**remedyUsers<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 ARSlist: "Where the Answers Are"_ >>> >>> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >>> >> >> _attend WWRUG12 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"
