We saw a race condition with ARS/ITSM 8.0 and 8.1 where FTS workflow searched the FTS index prior to a new record being indexed. The issue stopped when we unchecked Use FTS in Workflow.
Because the record had not been indexed yet, instead of finding the recently submitted CM request by the CHG ID as designed, a filter with a Set Field expecting the ID would set a field to NULL based on If No Request Match = Set Field to $NULL$. From there the remaining workflow was thrown off. Turned out the Infrastructure Change ID (1000000182) had been set to FTS and MFS and should have only been MFS Only. After changing the field back to MFS Only we were able to re-enable Use FTS in Workflow. This was before the FTS Fortification <https://communities.bmc.com/community/bmcdn/bmc_remedy_ar_system/blog/2013/08/30/the-pulse-fts-fortification> info was published so I suspect a lack of tuning was at play. Jason On Wed, Oct 28, 2015 at 6:48 AM, Jithin T.R < jithin.t.radhakrish...@gmail.com> wrote: > ** > Hi Michelle, > > Sorry for the delay in response. > > Thanks a lot for your suggestion. > > However, our issue was with FTS, as of now we just disabled o FTS on > workflows and that resolved the issue. We are looking into root cause of > the issue. > > Best Regards, > Jithin > > > > On Wed, Oct 7, 2015 at 7:15 PM, Lucero, Michelle < > michelle.luc...@bankofamerica.com> wrote: > >> ** >> >> Hi, Jithin: >> >> >> >> I am not sure if the error you’re seeing is related to FTS. >> >> >> >> In the past we’ve seen mismatches, because of an added middle initial, >> name, space, etc. We’ve also had a format mismatch, where an older record >> was stored First Name Last Name and the People record was stored Last Name, >> First Name. >> >> >> >> 1. Compare the Full Name for this individual in these three places: >> >> · CTM:People >> >> · CTM:SupportGroupFunctionalRole >> >> · User >> >> >> >> The Full Name format in all three places must match. >> >> >> >> 2. One more thing. Check to see if this individual has the same full >> name as someone else? >> >> >> >> Hope this helps, >> >> Michelle >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Jithin T.R >> *Sent:* Tuesday, October 06, 2015 2:37 AM >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: FTS Re-index issue >> >> >> >> ** >> >> Hi Manoj, >> >> >> >> Thanks you. >> >> >> >> The user form and permission are set up for this user without any issue. >> >> >> >> From my knowledge I don't think Functional Role are mapped in user form. >> >> >> >> Actually there are some workflows setting some temporary values while >> setting the Change Manager value in the field. This value will be set if >> there is a record CTM:SupportGroupFuncRoleLookUp with Full Name we selected >> from the list. >> >> >> >> I think because of the FTS issue, the system is unable to search the >> records using Full Name and in turn throws an error stating Invalid Change >> Manager. >> >> CHG:CRQ:ValidateChgManager_145 it is searching record using fullname >> >> CHG:CRQ:ValidateChgManager_146 this one is throwing error >> >> >> >> Best Regards, >> >> Jithin >> >> >> >> On Tue, Oct 6, 2015 at 12:25 PM, Manoj Kumar <manoj.anup...@gmail.com> >> wrote: >> >> ** >> >> Jithin, >> >> Check in user form once if the permission exists and try to re-add the >> permission. >> We had same issue and it worked . >> >> Thanks, >> Manoj >> +91 996 223 2006 >> >> Sent from my Moto Turbo smart phone >> >> On 6 Oct 2015 11:33, "Jithin T.R" <jithin.t.radhakrish...@gmail.com> >> wrote: >> >> ** >> >> Hi All, >> >> >> >> Thanks a lot for your valuable time on this. >> >> >> >> *"The issue we are facing is when we try to assign a change request to >> change manager system throws an error stating Invalid change manager. We >> have everything configured for that users.* >> >> >> >> *When we searched the record for that user in >> CTM:SupportGroupFuncRoleLookUp using Login ID it retrieves all the >> records. However, when try it with full name no records found."* >> >> >> >> We are on Remedy 8.1 and have 2 servers. >> >> >> >> Both servers are configured as Server Group-Indexer in FTS Configuration >> form, there is no Server Group-Searcher defined and both servers have entry >> in Server Ranking form for FTS. >> >> >> >> Is this mandatory to have a Server Group-Searcher ? or based on ranking >> in Server Group Ranking form, will lower ranked server automatically turns >> into Searcher ? >> >> >> >> Best Regards, >> >> Jithin >> >> >> >> >> >> On Tue, Oct 6, 2015 at 8:17 AM, William Rentfrow < >> wrentf...@stratacominc.com> wrote: >> >> ** >> >> We're in the process of testing version 9, so I can't comment on that yet. >> >> >> >> William Rentfrow >> >> wrentf...@stratacominc.com >> >> Office: 715-204-3061 or 701-232-5697x25 >> >> Cell: 715-498-5056 >> >> >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@ARSLIST.ORG] *On Behalf Of *Peter Romain >> *Sent:* Monday, October 05, 2015 3:51 PM >> >> >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: FTS Re-index issue >> >> >> >> ** >> >> FTS has changed since Williams description. >> >> >> >> Indexes should now be on the disks of the servers doing the indexing for >> improved performance. >> >> Each indexing server creates its own index that it uses for searches. >> >> Servers that are not indexers (those having no FTS record in the server >> group ranking form) use the primary indexing server for searches. If this >> server isn’t available the ranking form tells them which server to try next. >> >> Community posts discuss FTS, e.g.: >> >> >> https://communities.bmc.com/community/bmcdn/bmc_remedy_ar_system/blog/2013/10/11/the-pulse-high-availability-for-fts-in-a-server-group >> >> >> >> The fortification does work to reduce the number of fields needing >> indexing but we found that adding a customisation to, say, the incident >> form caused the index information on indexed fields to propagate to >> incident join forms and then be indexed. >> >> BMC was going to fix this but I’ve not tested this on the latest versions. >> >> >> >> >> >> >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *William >> Rentfrow >> *Sent:* 05 October 2015 16:47 >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: FTS Re-index issue >> >> >> >> ** >> >> I disagree. You do NOT want to re-index from every server. >> >> >> >> First of all - what version of ARS? Let's assume it's version 8 or >> later. >> >> >> >> Second - when you re-index there's a specific process. You should >> disable FTS on all servers and disable indexing on all servers. Then shut >> them all down. Delete all of the index files from the shared index >> location (see below). Use a SQL tool and truncate the table FT_PENDING (or >> write a Display Only form + workflow to do this, which is what I did for >> long term ease of use). Then start the admin server and enable indexing. >> Then start a re-index. Start the other servers back up and turn FTS back >> on when the re-index is done. >> >> >> >> Now as to configuration.... >> >> >> >> There's more than one way to do it but BMC definitely has a preferred way. >> >> >> >> In a server group BMC prefers you have a shared file location all servers >> can access. One server - usually the admin server for the server group - >> is the indexing server. It creates all of the index files and updates the >> files when new requests are put into the FT_PENDING table. >> >> >> >> One of the other servers (or the other server if you only have two >> servers) is the search server. It should have FTS indexing disabled and >> should be configured to retrieve all searches for FTS. So all of the >> plugins in the ar.conf/ar.cfg on every server should reference the search >> server. This prevents file locking problems. >> >> >> >> Also, there is an FTS fortifications patch out that removes a LOT of >> extra/unused indexes and GREATLY reduces the amount of time it takes to do >> a full re-index. I highly recommend applying this if you have not. >> >> >> >> William Rentfrow >> >> wrentf...@stratacominc.com >> >> Office: 715-204-3061 or 701-232-5697x25 >> >> Cell: 715-498-5056 >> >> >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *Durga, >> V H V Sekhar >> *Sent:* Monday, October 05, 2015 8:59 AM >> *To:* arslist@ARSLIST.ORG >> *Subject:* Re: FTS Re-index issue >> >> >> >> ** >> >> You need to re-index from both the indexer servers. >> >> >> >> *From:* Action Request System discussion list(ARSList) [ >> mailto:arslist@ARSLIST.ORG <arslist@ARSLIST.ORG>] *On Behalf Of *Jithin >> T.R >> *Sent:* 05 October 2015 06:55 >> *To:* arslist@ARSLIST.ORG >> *Subject:* FTS Re-index issue >> >> >> >> ** >> >> Hi Team, >> >> >> >> We have an issue, I cannot search using full name (Change Manager) and >> throwing error. >> >> >> >> This we have fixed by re-indexing. However, no we have an issue when we >> run re-index(only on primary server) it works fine in that server but not >> in other server. >> >> >> >> What is the procedure to FTS re-index in a server group environment ? >> >> >> >> We have 2 server both are configured as Server Group Indexer. >> >> >> >> Ranked the servers in Ranking form. >> >> >> >> Do we need to re-index each server ? >> >> >> >> >> >> Thanks & Regards, >> >> Jithin Radhakrishnan >> >> _ARSlist: "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.4830 / Virus Database: 4365/10744 - Release Date: 10/02/15 >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "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.4830 / Virus Database: 4365/10744 - Release Date: 10/02/15 >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> ------------------------------ >> This message, and any attachments, is for the intended recipient(s) only, >> may contain information that is privileged, confidential and/or proprietary >> and subject to important terms and conditions available at >> http://www.bankofamerica.com/emaildisclaimer. If you are not the >> intended recipient, please delete this message. >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _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"
