If you running 9.1 SP3 you can use the AR Upsert step, that can handle checksum.
https://docs.bmc.com/docs/ars91/ar-upsert-step-718087759.html -- J 2017-08-28 20:43 GMT+02:00 Scott Philben <sphil...@mac.com>: > ** > I am in the middle of this. Here is what I did (based on a thing I found > on Communities). You have to set a checksum value in the data stream the > first time you call AD. Then the second time you can do a DB call to the > table you are using (I have a staging form) and filter out the ones that > already exist based on that same checksum value. If there is no checksum > difference, it gets passed to Dummy, otherwise it goes through to the > AROutput step. > > Not quite done with testing it, but it seems to be doing what I need. > > [image: PastedImage-1.png] > > On Aug 28, 2017, at 02:37 PM, Joe D'Souza <jdso...@shyle.net> wrote: > > There is something funky about the AR API that is used by Pentaho Spoon. > If I recall correctly, the $OPERATION$ value at the time of create as well > as update is CREATE. Something funky like that. I do not recall specifics, > but you could try a small experiment to ascertain this for yourself. > > > > Create a filter on Remedy that writes to a temp field the $OPERATION$ > value. You will notice that irrespective of the type of operation, the > $OPERATION$ value is always CREATE. > > > > So in effect it appears like Pentaho really does not know the difference. > I didn’t have the opportunity to look deeper into this at the time I was > working on a Spoon job recently, but it appeared to me like it processes > all records irrespective during a execution.. Thankfully since Pentaho does > a massive update using a data pipe that can be sized appropriately > according to the expected size of the feeds, performance is not really that > much of a concern if you have your JVMs configured correctly. > > > > One way to process only the delta from the AR side would be to have > Pentaho work on a staging form instead of the load form, and then have > similar workflow like the load form to check for duplicates on both the > People and the Load form and process only those records that do not get > tagged as a duplicate on either the load nor the people form. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Shivanand Jeerigiwad > *Sent:* Monday, August 28, 2017 7:21 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: [Non-DoD Source] Need input on Delta load - Spoon client > > > > ** > > Hi Ryan, > > > > Yes, i am passing.. My scenario is like in a day if i process 100 records > it successfully creates people record. But the next day it should not > consider the same old records unless if it is not updated at LDAP side. How > i can achieve this? > > > Regards, > > Shiva > +91 9986985798 <+91%2099869%2085798> > > > > > > On Mon, Aug 28, 2017 at 4:47 PM, Nicosia, Ryan J CTR USSOCOM SOCOM J631 < > ryan.nicosia....@socom.mil> wrote: > > Are you passing "VALIDATELOAD" into z1D_Action field? That triggers the > workflow to run. > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Shivanand Jeerigiwad > Sent: Monday, August 28, 2017 6:32 AM > To: arslist@ARSLIST.ORG > Subject: [Non-DoD Source] Need input on Delta load - Spoon client > > ** > Hi team, > > I am trying to achieve the LDAP People Integration. I can able to pull > people records from LDAP server to BMC staging i.e CTM:LoadPeople form. > However, not getting how to achieve the delta load. > > If anybody has done, please let me know. > > > Regards, > > Shiva > +91 9986985798 <+91%2099869%2085798> > > _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" > > > > _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"
