Re: Modify a View Form entry using Java API
Thanks Carey. That was helpful... Since I come from the DB bunch, I too think of Filters as RDBMS Triggers.:) And you are right, with Bulk Transactions, i would expect some benefit from preventing mutliple trips across the network. We finally found that the delay in a thread going to the next API call was a bad corrupted index for one of the Filters that fired for the Modify API call. :| Once we fixed that index, we were able to configure our test bed server with a Private Program Number having min - 4 threads / max - 12 threads and had the Java program hit it with 100 Java threads. We were able to get a throughput of 4 records completing Modifications per second. Arthur Carey Matthew Black wrote: > > Arthur, > > "each thread would be relieved as soon as the modify of that one > record is completed in the View form" > > You are completely correct about that. However, where you think > "completed" should be reached is actually not where it actually ends. > > The transaction (or API call if you prefer) is not complete until > after all filters for that ARS Server operation has completed. If you > think of ARS as an application server then I think your applying a bit > to "modern" of a model than what ARS is actually modeled after. I > think you need to consider ARS more of an data store in the more > modern "application server" model. In fact I have often thought of > filters more as a RDBMS trigger than as a "workflow engine" portion of > an application server. ( And I can easily see how modern programmers > would see them differently.) > > So... in short... until after all of the filters have finished, the > ARS server does not commit (fully) the RDBMS data changes that might > be necessary for the API call. And thus, the event is not complete > until the transaction is fully committed to the data store. Then the > ARS server returns a "status code" describing any Messages or error > conditions that were issued during the transaction back to the caller. > That is the completion of the API call. > > Or at least that is how I see the ARS API universe. > > Now if you turn to the C API, there might be a better option... > > Specifically I would look at ARBeginBulkEntryTransaction as a possible > way to package and send multiple transactions as a single unit. You > however get a list of "status code"s per each api call that was sent > in the BulkEntry. > > > Maybe in the v7.1 Java API there will be an equivalent > ARBeginBulkEntryTransaction type of function, but for now, I do not > know of any interface to that feature set of the C API. > > But I will also add... that I would expect the client program to be > "held" waiting for the list of status codes from the bulk transaction > just as it would for a single transaction. I just hope that there is > some efficiency's gained by sending them as a set instead of in > multiple trips across the network. I would also expect that multiple > server threads would be tied up dealing with a single > ARBeginBulkEntryTransaction too. (But that is mostly speculation as I > do not speak C. :) > > 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: >> 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 > > ___ > 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-using-Java-API-tf4308465.html#a12285395 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"
Re: Modify a View Form entry using Java API
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: arslist@ARSLIST.ORG >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"
Re: Modify a View Form entry using Java API
Arthur, "each thread would be relieved as soon as the modify of that one record is completed in the View form" You are completely correct about that. However, where you think "completed" should be reached is actually not where it actually ends. The transaction (or API call if you prefer) is not complete until after all filters for that ARS Server operation has completed. If you think of ARS as an application server then I think your applying a bit to "modern" of a model than what ARS is actually modeled after. I think you need to consider ARS more of an data store in the more modern "application server" model. In fact I have often thought of filters more as a RDBMS trigger than as a "workflow engine" portion of an application server. ( And I can easily see how modern programmers would see them differently.) So... in short... until after all of the filters have finished, the ARS server does not commit (fully) the RDBMS data changes that might be necessary for the API call. And thus, the event is not complete until the transaction is fully committed to the data store. Then the ARS server returns a "status code" describing any Messages or error conditions that were issued during the transaction back to the caller. That is the completion of the API call. Or at least that is how I see the ARS API universe. Now if you turn to the C API, there might be a better option... Specifically I would look at ARBeginBulkEntryTransaction as a possible way to package and send multiple transactions as a single unit. You however get a list of "status code"s per each api call that was sent in the BulkEntry. Maybe in the v7.1 Java API there will be an equivalent ARBeginBulkEntryTransaction type of function, but for now, I do not know of any interface to that feature set of the C API. But I will also add... that I would expect the client program to be "held" waiting for the list of status codes from the bulk transaction just as it would for a single transaction. I just hope that there is some efficiency's gained by sending them as a set instead of in multiple trips across the network. I would also expect that multiple server threads would be tied up dealing with a single ARBeginBulkEntryTransaction too. (But that is mostly speculation as I do not speak C. :) 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: > 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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Modify a View Form entry using Java API
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-using-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"
Re: Modify a View Form entry using Java API
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-using-Java-API-tf4308465.html#a12267279 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"
Re: Modify a View Form entry using Java API
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"
Modify a View Form entry using Java API
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 -- View this message in context: http://www.nabble.com/Modify-a-View-Form-entry-using-Java-API-tf4308465.html#a12265229 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"
