Thanks Misi!
In this particular case I dealing with a single server environment with low
traffic. So I went ahead, changed the Block Size to 1 and I’m getting the
nextId from the Metadata arschema form. So far it works just fine.
If I encounter difficulties though I’d probably have no choice but use an
staging form and try the trick you mentioned.
--Thomas
> On 13. Oct 2017, at 14:12, Misi Mladoniczky <m...@rrr.se> wrote:
>
> **
> Hi,
>
> Any other tool, such as a plugin sver, would actually go through the AR
> Server eventually before the Request ID is used and a record is created.
>
> There are two settings which you can play around with, and these would revert
> back to the old behaviour of locking the table and increasing one step at a
> time:
> Next-ID-Commit: F NextID-Block-Size: 1
>
> And as the Block-Size can be set on a form level to one, it might not be too
> bad for performance.
>
> But it might be hard to control anyway, as you have multiple servers and
> threads, and they can be in the process of creating records more or less
> simultaneously. So if you get the NextID in a filter, you might still get the
> wrong one...
>
> It would be great if BMC had an oprtion to do an
> Application-Reserver-Request-ID call, which you could call from an ACTL or
> from a FLTR in order to immediately book the a Request ID and populate field
> 1.
>
> But at the moment there is no such thing, which is also why BMC now
> extensively uses the GUID-field instead of the Request ID, where you can get
> this functionality.
>
> In your situation Miskiewicz, I would create my own way to reserve unique
> numbers, and use that instead of the built in Request ID.
>
> There was an old trick, but I am not sure it will be future secure, and that
> was to do a Filter Push-Fields to yourself so to speak, where the
> qualification would be ('1' = $1$). You can then set a
> display-only-trigger-field to trigger whatever workflow you need. This would
> happen immediately after the record has been commited to the database, so you
> do not need to wait for an escalation.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se <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
> <http://rrr.se/>
>
>
>
>
> October 13, 2017 1:53 PM, "Rick Cook" <remedyr...@gmail.com
> <mailto:%22Rick%20Cook%22%20<remedyr...@gmail.com>>> wrote:
> **
> Randeep, yes, all requests flow THROUGH AR Server, but not all are generated
> directly BY it. Outside products would likely use a plug-in server thread,
> which creates the competition with direct AR Server calls for the Next ID
> calls.
> Thomas, Notify already runs in Phase 3 - there is no "later phase". Run Order
> can be used within that phase to set an order of operation.
> Rick Cook
> On Thu, Oct 12, 2017 at 11:07 PM, Randeep Atwal <ratwals...@gmail.com
> <mailto:ratwals...@gmail.com>> wrote:
>
> **
> Other idea(s)
> Idea 1
> For just the Request ID instead of looping a table field, you can include it
> statically in the subject and/or body line of the email. Since notify actions
> run after the database commit occurs. You lose the template niceties for this
> one field, but I think it's manageable since all notifications need a
> reference ticket usually, and having it in the same format is realistic.
> 2 Create a new field for Incident ID - separate from the system generated
> Request ID (FieldID 1) Since you are talking about using Request ID I guess
> you are not using the BMC ITSM, app, and this is a custom app. But there is
> nothing to stop you creating push field filter workflow that creates a unique
> Incident Number in phase 1 filter processing that would be available. You
> would create a form that does nothing but generate numbers, and use $LASTID$
> to get the number This would likely be painful to retrofit if you already
> have lots of references to the request id all over the place.
> On Thu, Oct 12, 2017 at 10:43 PM, Thomas Miskiewicz <tmisk...@gmail.com
> <mailto:tmisk...@gmail.com>> wrote:
> **
> Randeep, we don’t like the out of the box email templates so we’ve build our
> own app. In that Workflow I loop through a table field to replace variables
> of a template with the ticket data. Overwriting the filter phases means I
> don’t have access to the Request ID when I need to send the notification.
> Ticket $Request ID$ has been created ends up being Ticket has been created.
> Answering your question we arrive at another problem in BMC Remedy: no
> control over filter phases for the user. Why cannot I postpone Notify to a
> later phase on demand?
> It looks like I got two options left:
> 1. Set block size to 1
> 2. Instead of sending that email immediately push it to a staging form and
> run an escalation to send emails after the holy grail Request-ID is finally
> there.
> 3. Any other ideas?
>
> On 13. Oct 2017, at 04:08, Randeep Atwal <ratwals...@gmail.com
> <mailto:ratwals...@gmail.com>> wrote:
>> **
>> Rick, everything that generates NextID's must come through an ARSystem
>> server so I don't know what you mean when you say 'If you have multiple
>> outside entities creating large number of records at once'
>> All requests go through the AR Server.
>> I would theorize that you may have other factors in play once you remove the
>> NextID bottleneck by using chunks of 100. Something to bear in mind is that
>> by chunking NextID's, you cause the scalability of the system to go up (i.e.
>> more records per second getting created) - but the per record response time
>> under high load is likely to go down (due to the system being under heavy
>> load, other downstream constraints such as CPU/Disk Speed start to appear,
>> where they would not appear if the NextID bottleneck was in place) It
>> effectively acts as a throttle. So your results could be easily
>> misinterpreted.
>> I would think a way to confirm this is to generate parallel load from a high
>> number of worker threads, and time how long it took to reach the same number
>> of records created with 1 or 100 for the NextID chunk size. Then compare the
>> times. Anyway, we are off on a tangent from the original topic
>> Thomas, I am actually curious as to why you want to know a nextid. What
>> Abhijeet said explains why it doesn't make sense to ask for it, but often in
>> workflow scenarios, where you want to generate something unique and
>> refer/tie back to something else. you are better off using
>> Application-Generate-GUID [" GUIDPrefix" ]
>> On Thu, Oct 12, 2017 at 5:27 PM, Rick Cook <remedyr...@gmail.com
>> <mailto:remedyr...@gmail.com>> wrote:
>> **
>> Abhijeet, my results were repeated and conclusive. Here is the only logical
>> explanation for my findings that makes sense:
>> There is a time cost to the DB call for Entry IDs. The cost increases
>> incrementally the more that are requested at once. The thought is that 100
>> individual requests will take substantially more time than retrieving 100
>> IDs in one request. That thought has been proven to be correct - it's why
>> the feature was added. However, the difference in time was tested against a
>> system that had multiple sources (NMS) attempting to grab multiple Entry IDs
>> at the same time, not a normal system without those multiple outside
>> requests, because it was the first environment that was reporting the
>> problem with performance.
>> On a system where the volume of IDs is high enough to cause a system
>> bottleneck at the DB ID request, which requires multiple simultaneous
>> requests from different sources, that bottleneck costs more additional time
>> than is lost by the increased time it takes to request multiple IDs at one
>> time. However, on a system that is not bound by the Next ID calls to the DB,
>> or has only a single source (AR System) requesting IDs, there is no
>> advantage gained by the multiple requests, because the time "gained" by
>> having a cached ID is negligible - too small to even notice. And, as my
>> testing proved (to my surprise), there was an increasing net cost to system
>> performance as the number of IDs requested in a single call grew. This must
>> be because the time it takes to gather, say, 100 records in one call is
>> actually *higher* than it is to do 100 individual calls - IF AR System is
>> the only source of those calls. The simple correlation is that if AR System
>> is the only thing generating new Request ID requests to the DB, you don't
>> need, and will not benefit from, a number larger than 1. If you have
>> multiple outside entities creating large number of records at once, you very
>> well may benefit from it.
>> My tests that showed decreasing performance as the Next Id block grew were
>> creating about 1.5 million records, but, and this is important - all were
>> from the same source - AR System workflow. There were no other simultaneous
>> demands on the table, and few on the system. Therefore, the system of
>> generating one ID at a time had a cumulatively lower transaction time than
>> it did when it had to wait for multiples to be retrieved and then allocated
>> individually. The BMC Engineer, who I know to be very smart and experienced
>> with Remedy, had no explanation for my results. I believe this to be that
>> BMC didn't test against a control (normal) system, and therefore had no data
>> on its effect on them.
>> Why then, they chose to recommend that setting to all customers, is a
>> mystery to me.
>> Rick Cook
>> On Thu, Oct 12, 2017 at 4:56 PM, Gadgil, Abhijeet <abhijeet_gad...@bmc.com
>> <mailto:abhijeet_gad...@bmc.com>> wrote:
>> **
>> Rick, I do not think that is accurate.
>>
>> Logically, if the block size is 100 then the server will access the DB once
>> to retrieve the next block id every 100 records. If it is 1, then the server
>> goes to the DB for every record.
>>
>> Later cannot be faster.
>>
>> Further, to answer the original question, returning the next id in an API
>> call would mean preventing creation of ids by anyone other than the caller
>> until the id has actually been used -- otherwise the information might be
>> obsolete before the client receives it. That is the reason for not exposing
>> it via an API
>>
>> Regards,
>>
>> Abhijeet
>>
>> From: Action Request System discussion list(ARSList)
>> [mailto:arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG>] On Behalf Of Rick
>> Cook
>> Sent: 13 October 2017 02:12
>> To: arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG>
>> Subject: Re: What's the NextId?
>>
>> **
>>
>> Here's the skinny on that. I got this from the engineer who built that
>> feature, btw.
>>
>> The problem was that system performance was being constricted around the
>> action of getting the NextId for a record when multiple sources (say,
>> Netcool and HPOV) were throwing tons of requests at the (Incident) form at
>> the same time. The process of getting each Next Entry ID in individual DB
>> calls was bottlenecking the process of creating the records. So that's why
>> BMC came up with a way to pre-allocate those in bulk, so that only every N
>> times (whatever the number is set to) would an actual call to the DB to get
>> Next IDs be necessary. The transaction time to retrieve 1 or 100 wasn't much
>> different, and those customers with multiple programs requiring many
>> simultaneous record creations saw a marked performance increase. It was, and
>> is, a good feature add.
>>
>> So (then a miracle occurs) and BMC announces that this particular corner
>> case had a solution that everyone should benefit from, and announced that
>> the number should be 100 for *all* customers. I tested this back in 7.6.04
>> against a RH server, with settings at 1, 10, 100, and 1000, and found that
>> performance was actually NEGATIVELY affected the higher the number was set.
>> It wasn't a huge difference (10%~), but it was a clear, repeatable one for
>> which BMC's engineer had no explanation. It is why I have always advocated
>> that unless a customer has the specific set of circumstances that caused the
>> feature to be beneficial, there is no real benefit to setting the number
>> larger than 1. And there are minor drawbacks to doing so, the current
>> subject being one of them.
>>
>> Every time I ask someone from BMC to justify a larger number to the average
>> customer, they repeat the party line, unaware of the history behind the
>> feature. I will continue to tilt at this windmill until someone at BMC shows
>> me some performance testing numbers that justify this setting for the entire
>> customer base.
>>
>> Rick
>>
>> On Oct 12, 2017 13:30, "Thomas Miskiewicz" <tmisk...@gmail.com
>> <mailto:tmisk...@gmail.com>> wrote:
>>
>> **
>>
>> i.e. there is no hack to find out the nextID before it actually gets
>> submitted?
>>
>> Apart from that, I really don’t understand why BMC makes such a fuss around
>> the nextID. Why can’t they just provide a special command GET-NEXTID?
>>
>> Thomas
>>
>> On Oct 12, 2017, at 10:26 PM, LJ LongWing <lj.longw...@gmail.com
>> <mailto:lj.longw...@gmail.com>> wrote:
>>
>> **
>>
>> There are no interfaces that I'm aware of to ask a specific server what the
>> next id it will hand out for a specific form is
>>
>> On Thu, Oct 12, 2017 at 2:14 PM, Thomas Miskiewicz <tmisk...@gmail.com
>> <mailto:tmisk...@gmail.com>> wrote:
>>
>> Hello List,
>>
>> with NextID Block size being set to 100 —> is it possible the find out using
>> the API which will be the next Request-ID that the server will assign to a
>> request? Or what other options do I have to find out?
>>
>>
>> --Thomas
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> <http://www.arslist.org/>
>> "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_
>> _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_
> _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"
