Use Merge with the NoWorkflow option (a bit pattern available since ARS 6+) instead of Modify AND set a real database field so that an escalation fires the real Modify workflow. Obviously, build that escalation.
You are getting around the basic design of ARS in this way and this must be done with a bit of thought... Also note that there are performace problems with escalations including running in a single server thread and a delay of firing that may be up to a minute (if the esc is set to fire every minute). Obviously, place an appropriate index for that escalation. While you will increase the performance of your Java app, you may decrease overall performance. Again, a bit of thought is needed. Submit / Modify / Merge (with filters option) always wait for completion of all filters. There is no database commit until all filters fire, so the modify is not done until all filters fire (for all tables if there are any pushes). A filter can cause an error which is reflected back in the return code of the Submit / Modify / Merge API call. The `! simply alters the phasing of that filter. All of the above text still holds. Even the special commit run process will not alter the fact that all filters must complete before the modify is considered complete. Cheers Ben Chernys www.softwaretoolhouse.com >----- ------- Original Message ------- ----- >From: arthurj ><[EMAIL PROTECTED]> >To: [email protected] >Sent: Tue, 21 Aug 2007 20:18:32 > >I would think that each thread would be relieved as >soon as the modify of >that one record is completed in the View form and >not wait for the Modify >filters depending on that Modify to complete, since >there are no Filters >with names ending in "`!". > >Arthur > > >arthurj wrote: >> >> Thanks Carey. >> The Java program I mentioned earlier is a >multithreaded app which sends in >> 8 threads to a Private server 390682 (min 4 and >max 8 threads). Each >> thread is a Modify request to that View form. >> From the logs it seems like every thread waits >for all the relevant Modify >> Filters to complete, before a second modify >request can be sent in using >> that thread. >> >> Arthur >> >> >> Carey Matthew Black wrote: >>> >>> Dear Arthurj (software_architect), >>> >>> To my knowledge there is no way to alter the >atomic nature of the ARS >>> API. (vai the Java API or the C API.) The >"trick" is to realize that >>> the ARS server is a multi-threaded server. You >can control how your >>> client talks to the ARS server and how many >threads are available to >>> your client program. But the magic starts with >the RPC program number >>> you use in the connection to the ARS server. >>> >>> Hope that helps. >>> >>> -- >>> Carey Matthew Black >>> Remedy Skilled Professional (RSP) >>> ARS = Action Request System(Remedy) >>> >>> Love, then teach >>> Solution = People + Process + Tools >>> Fast, Accurate, Cheap.... Pick two. >>> >>> >>> On 8/21/07, arthurj ><[EMAIL PROTECTED]> wrote: >>>> Wanted to see if anyone has info for the >following case. >>>> >>>> There are a bunch of Filters defined for a >Modify operation on a View >>>> form. >>>> An external Java program sends in multiple >Modify requests to this form. >>>> >>>> When we use an external Java program to modify >records in this View >>>> form, >>>> once a Modify request is sent to the server, >would every Modify request, >>>> wait for all the relevant Modify Filters to >complete? >>>> Wanted to know if it's possible to get the >control back from the server, >>>> without every Modify request having to wait for >all the Filters, >>>> relevant to >>>> that Modify to complete, before going on to the >next Modify request to >>>> be >>>> sent to the server. >>>> >>>> Thanks >>> >>> >___________________________________________________ >____________________________ >>> UNSUBSCRIBE or access ARSlist Archives at >www.arslist.org ARSlist:"Where >>> the Answers Are" >>> >>> >> >> > >-- >View this message in context: >http://www.nabble.com/Modify-a-View-Form-entry-usin >g-Java-API-tf4308465.html#a12267281 >Sent from the ARS (Action Request System) mailing >list archive at Nabble.com. > >___________________________________________________ >____________________________ >UNSUBSCRIBE or access ARSlist Archives at >www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
