[ADV] Screenshots of the ARSmarts Data Manager on our website.
Hello List, Better late than never: we added some screenshots of the Data Manager module on our website (www.arsmarts.com). Best regards, Kaïs. kais.albas...@arsmarts.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: ARS 7.6.04 install on Linux using Command Line
Hi Paul, I am also stuck with exactly the same, need to perform ARS v7.6.04 silent installation on linux. Would really appreciate if you could send me the sanitized sample you are referring to in your post. Regards, Saurabh -- View this message in context: http://ars-action-request-system.1.n7.nabble.com/ARS-7-6-04-install-on-Linux-using-Command-Line-tp112919p117007.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Need the Service Targets to start measuring from Date and time field - WO Type Field 06.
Hi All, We Need the Service Targets to start measuring from Date and time field - WO Type Field 06. So SVTs start when condition used is - WO Type Field 06'= $\TIMESTAMP$ .( WO Type Field 06 is a date and time field on work order form) But SVTs remains attached only even after the date and time mentioned in WO Type Field 06. SVTs moves into in-progress only when there is a modification on request after WO Type Field 06 time. -thanks harry ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Transactional (TR) and Database (DB)
I think there's a few reasons. First, using TR. is redundant. Every value in a filter (unless it already has DB. in front of it) is by it's nature a transactional value. There's literally almost no reason to use, it, EXCEPT that it makes the code a bit more clear from a visual standpoint if you do decide to use DB. on a field. I think the reason most people don't use DB. on field workflow is that it's kind of perceived as lazy. Let's say you want to check and see if a phone # has changed. You can either use the Phone != DB.Phone at runtime - or you can do an actual lookup with some separate workflow prior to this action. That gives you greater control over the action going on for the most part. That said, it's just my opinion and I'm sure there's lots of place people have used both and been perfectly happy with it. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith Sent: Thursday, May 08, 2014 10:22 AM To: arslist@ARSLIST.ORG Subject: Transactional (TR) and Database (DB) Hi List, We can achieve things without using TR and DB values in a filter by just using Field but I do not understand why they have been developed to use? I have heard from many remedy developers like Misi and BMC who suggest not to use TR and DB in Run If qualification of a filter but why? Why it is not recommended to use TR and DB values? What if I use TR.Field=DB.Field? Will it yield a correct result? In BMC documentation also they have not given any example where they used TR and DB together in a qualification. Appreciate your thoughts! Cheers, James ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: 05/05/14 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Transactional (TR) and Database (DB)
Hi Joe and LJ, You are wrong on Case 1: If you set the City to Gotham, it will have a TR-value of Gotham even on a Create. Case 2 is nothing much to say about. The problem with the TR value is: A. If the value is NOT changed it can both be set or be empty during a Modify. This depends on the client and how they use the API. For example a Push-Fields will always send a value, but a normal Save will only send a value if it has been changed. B. A value that is changed to NULL can not be distinguished from a value that is not sent in the transaction. Both situations will match a 'TR.Field' = $NULL$. Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. While most of everything you stated is in sync with my understanding of TR, there is one small difference. MAYBE, I'm wrong and if so, I would love to be corrected. I can best explain this with an example. Lets say a record is created and there is a field called 'City' and during creation, that field was set to Gotham.. Case 1: When there is no change in the 'City' value during the modification. 'City' = Gotham 'TR.City' = $NULL$ (as there was no transactional change in the value) 'DB.City' = Gotham Case 2: When the value in the field 'City' is changed during a modification to Xanadu 'City' = Xanadu 'TR.City' = Xanadu 'DB.City' = Gotham So according to my understanding, it is incorrect to say that 'TR.City' is the same as 'City' at all times. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Friday, May 09, 2014 9:28 AM To: arslist@ARSLIST.ORG Subject: Re: Transactional (TR) and Database (DB) I think there's a few reasons. First, using TR. is redundant. Every value in a filter (unless it already has DB. in front of it) is by it's nature a transactional value. There's literally almost no reason to use, it, EXCEPT that it makes the code a bit more clear from a visual standpoint if you do decide to use DB. on a field. I think the reason most people don't use DB. on field workflow is that it's kind of perceived as lazy. Let's say you want to check and see if a phone # has changed. You can either use the Phone != DB.Phone at runtime - or you can do an actual lookup with some separate workflow prior to this action. That gives you greater control over the action going on for the most part. That said, it's just my opinion and I'm sure there's lots of place people have used both and been perfectly happy with it. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith Sent: Thursday, May 08, 2014 10:22 AM To: arslist@ARSLIST.ORG Subject: Transactional (TR) and Database (DB) Hi List, We can achieve things without using TR and DB values in a filter by just using Field but I do not understand why they have been developed to use? I have heard from many remedy developers like Misi and BMC who suggest not to use TR and DB in Run If qualification of a filter but why? Why it is not recommended to use TR and DB values? What if I use TR.Field=DB.Field? Will it yield a correct result? In BMC documentation also they have not given any example where they used TR and DB together in a qualification. Appreciate your thoughts! Cheers, James ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: 05/05/14 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Set Month End Date
Hi, Please don't use char-fields like this. They are dependent on the language settings, and will be unpredictable especially on the client side via Active Links. Best Regards - Misi, RRR AB, http://rrr.se The DateNum function is your friend here, try this Have a temp character field and set it to be: Temp Character = (DATENUM(mm, $DATE$) +1) + /1/) + YEAR($TIMESTAMP$) (You may have to reformat this a bit depending on Locale) Then have another set fields into a temp date field that does Temp Date = $Temp Character$ Then one more that does DueDate = $Temp Date$ - 1 I haven't tested this but it should work From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Karthick S Sent: Wednesday, May 07, 2014 3:50 AM To: arslist@ARSLIST.ORG Subject: Set Month End Date ** I need to Set a Month End Date in a field Called Due Date. Please find the below. Example: Ticket created Date is 7/05/2014 12:00:00 AM and the Due Date should have 31/05/2014 11:59:59 PM. it should automatically calculate or populate the Month End Date in Due Date field. I have used this condition ($DATE$ + 43200) + (86400 * 31)) - (86400 * DAY((($DATE$ + 43200) + (31 * 86400) - (3600 * HOUR((($DATE$ + 43200) + (31 * 86400) + (DAY($DATE$) * 86400)) - 1, Which given me the Due Date as 7/06/2014 11:59:00 PM. Can any one help me on this, Please. _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years -- This message was scanned by ESVA and is believed to be clean. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: API for SRM Services
Hi, You are very limited with what you can do with the interfaces for SRM. The BMC Communities has a plethora of information on what you can and cannot do and how to do it. The best way if using an external program would be to show the service in a frame utilising a direct link and OOB functionality (due to the lack of functionality on the interface forms i.e. no question submission through the OOB interface forms). If you wanted to do more i.e. populate questions, then you have to understand all the underlying CAI structures and how it all interacts. Kind regards, Carl Wilson Missing Pieces Software Solutions -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Sweety Sent: 08 May 2014 23:05 To: arslist@ARSLIST.ORG Subject: API for SRM Services Hi Experts, I am tryint to create API program for services in SRM but finding it difficult to figure out how? Which form should I refer to list the services available in SRM? How about the fields? Each service will have different fields, how can I show these fields in my API UI? Please help me. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Transactional (TR) and Database (DB)
James, This is to allow you to, for a specific field, 1) Determine programmatically if a (user or automated) transaction has attempted to change the field value or not . OR - 2) Compare what the value used to be, just before the current transaction attempted to change it, as opposed to what it is being changed to. A good example of a use case for this is if you have a business rule requirement that neither users nor other systems or processes integrated to your form are allowed to change the Status of a record from Assigned to Closed, because you want them to set it to Resolved first, because; 1) You have other workflow and/or SLA's and/or reports that depend on the Status.History.Resolved.TIME to be populated. OR - 2) You have a quality control process that determines that a different group of users pick up the Resolved records and phones the customer back to find out if they are happy with the resolution and only then is the record to be set to Status = Closed. In either of these cases, you would implement these business rules quickly and easily through the relatively simple creation of a single Filter that Checks if 'TR.Status' = Closed AND 'DB.Status' != Resolved and returns an error. If you only use Status = Closed in this filter run if, you will end up with the filter getting triggered for updates that legitimately set Status = Closed as well. If you used an active link on Return/Menu Choice/Lose Focus of the Status field, sure, you would prevent your users from making an invalid change, but, any Filter Push Field or API integration update would still manage to do the invalid update because active links don't get triggered on that level. Sure, you can achieve the same result by adding lots of Temp fields doing set-fields from the database to get the old DB value for your fields, but this starts to get very messy if you; 1) Have multiple business rules that require you to do this type of comparison on multiple fields. (You could potentially end up duplicating almost all your fields on the form doing things this way). 2) Have to deal with confused user questions as to which field should we believe to hold the actual value for their reports if the fields are named similarly to avoid programmer confusion. 3) Have to add extra filters to do a relatively expensive and redundant second lookup on the database to find the old DB value for a field - which only serves to slow down your system. 4) Forget to change the lookup field attributes if the actual field attributes has been changed. Therefore, the need for Transactional (TR) and Database (DB) values on filter level. HTH. Best Regards, Theo -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith Sent: 08 May 2014 17:22 To: arslist@ARSLIST.ORG Subject: Transactional (TR) and Database (DB) Hi List, We can achieve things without using TR and DB values in a filter by just using Field but I do not understand why they have been developed to use? I have heard from many remedy developers like Misi and BMC who suggest not to use TR and DB in Run If qualification of a filter but why? Why it is not recommended to use TR and DB values? What if I use TR.Field=DB.Field? Will it yield a correct result? In BMC documentation also they have not given any example where they used TR and DB together in a qualification. Appreciate your thoughts! Cheers, James ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: OT: I just wanted to say Happy Mother’s day to all of the mothers on the list and the husbands that love them.
Thank you Howard! Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Richter, Howard (CEI - Atlanta) [howard.rich...@coxinc.com] Received: Sunday, 11 May 2014, 8:05AM To: arslist@ARSLIST.ORG [arslist@ARSLIST.ORG] Subject: OT: I just wanted to say Happy Mother’s day to all of the mothers on the list and the husbands that love them. ** For the mother’s Happy Mother’s Day to all of moms out there. We have so much respect for each of you. It does not matter how old your kids get, you will always put them first. Unknown author --- Now for the dad’s The most important thing a father can do for his children is to love their mother. Theodore Hesburgh http://www.brainyquote.com/quotes/authors/t/theodore_hesburgh.html Take care all. Howard Richter, Remedy Administrator _ARSlist: Where the Answers Are and have been for 20 years_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Transactional (TR) and Database (DB)
Hi, There is one single real benefit from using TR-values. If you have a field that is only referenced as 'TR.Field' in the run-if of any filter, the database value will not be retrieved during the transaction. This is a small performance benefit. If you have any non-TR field reference in the run ifs of your filters, the system will do a fetch from the database before filter processing has begun fetching all the DB-values that it needs for filter processing. Saving this fetch from retrieving one extra column to me seems like a small performance benefit anyway... It is all in the logs. Just turn them on and check it out for yourselves! Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. Some wonder why TR was built others say it works fine. I thought I had a good handle on TR but now reading the differing opinions I am questing my understanding of TR. Some posts indicate it is completely useless and can't be trusted. Some other indicate like a weapon as long as you treat it with respect and know how to you it you'll be fine. So off the the archives I went: http://ars-action-request-system.1.n7.nabble.com/TR-vs-DB-sanity-check-please-tp99981p3.html Doug set it straight in 2010. After rereading his post I am questioning the purpose of TR. QUOTE: 'A' != 'DB.A' is all the testing you need to see if the value has changed If DB all that is needed what is a valid use case for having TR. Not one that can be down with TR or DB but what is that TR provides that cannot be done otherwise? Jason BTW, hope this didn't post twice. I used the web UI because of the recent email issues but when I checked I don't see my reply which is usually instant on the web. I waited a few minutes and fired again. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
Re: Transactional (TR) and Database (DB)
While most of everything you stated is in sync with my understanding of TR, there is one small difference. MAYBE, I'm wrong and if so, I would love to be corrected. I can best explain this with an example. Lets say a record is created and there is a field called 'City' and during creation, that field was set to Gotham.. Case 1: When there is no change in the 'City' value during the modification. 'City' = Gotham 'TR.City' = $NULL$ (as there was no transactional change in the value) 'DB.City' = Gotham Case 2: When the value in the field 'City' is changed during a modification to Xanadu 'City' = Xanadu 'TR.City' = Xanadu 'DB.City' = Gotham So according to my understanding, it is incorrect to say that 'TR.City' is the same as 'City' at all times. Cheers Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow Sent: Friday, May 09, 2014 9:28 AM To: arslist@ARSLIST.ORG Subject: Re: Transactional (TR) and Database (DB) I think there's a few reasons. First, using TR. is redundant. Every value in a filter (unless it already has DB. in front of it) is by it's nature a transactional value. There's literally almost no reason to use, it, EXCEPT that it makes the code a bit more clear from a visual standpoint if you do decide to use DB. on a field. I think the reason most people don't use DB. on field workflow is that it's kind of perceived as lazy. Let's say you want to check and see if a phone # has changed. You can either use the Phone != DB.Phone at runtime - or you can do an actual lookup with some separate workflow prior to this action. That gives you greater control over the action going on for the most part. That said, it's just my opinion and I'm sure there's lots of place people have used both and been perfectly happy with it. -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of James Smith Sent: Thursday, May 08, 2014 10:22 AM To: arslist@ARSLIST.ORG Subject: Transactional (TR) and Database (DB) Hi List, We can achieve things without using TR and DB values in a filter by just using Field but I do not understand why they have been developed to use? I have heard from many remedy developers like Misi and BMC who suggest not to use TR and DB in Run If qualification of a filter but why? Why it is not recommended to use TR and DB values? What if I use TR.Field=DB.Field? Will it yield a correct result? In BMC documentation also they have not given any example where they used TR and DB together in a qualification. Appreciate your thoughts! Cheers, James ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: 05/05/14 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Where the Answers Are, and have been for 20 years
