Frank,
I don't know if you are eluding to another transaction or not with this
statement
.....
The update of the Main Form causes the filter to fire which, thru a push
fields action, is creating another record
....
But the bottom line is the local MainForm should only be a Modify, AND the
remote MainForm will see a Merge and a Modify.
The tricky part through this whole thing is that the $USER$ value will be
Distributed Server. So you could not use this in the qualification.
Is there any field value on Modify on the local MainForm, that would not be
detected on the remote MainForm Modify, after the merge operation?
Might I suggest that as part of the Push Field action you set a Display
Only scratch field and watch for $USER$ != Distributed Server on Create or
Modify. Then fire you filter on this.
The filter would never fire on the remote MainForm, because the Modify is
from the DSO transaction and not the Push Field action. It works because
the scratch field won't have a value in the DSO transaction.
You may need to play with shifting to Phase 1 .... aka `!
Chad
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Frank Caruso
<[EMAIL PROTECTED]
IL.COM> To
Sent by: "Action arslist@ARSLIST.ORG
Request System cc
discussion
list(ARSList)" Subject
<[EMAIL PROTECTED] Re: DSO and $OPERATION$
ORG>
10/17/2006 03:47
PM
Please respond to
[EMAIL PROTECTED]
RG
** I would expect the filter to fire after Temp Form updates the Main Form.
The update of the Main Form causes the filter to fire which, thru a push
fields action, is creating another record.
I think it would be #2.
However, we do not want that filter that fired on modify of the Main Form
on the prod server to run the replicate server.
On 10/17/06, Chad M Whilding <[EMAIL PROTECTED]> wrote:
Frank
So after which action are your expecting the filter to fire?
1. UK dso into your TempForm
You will see a MERGE by Distributed Server in your TempForm...AND...you
will see a MODIFY by Distributed Server in your TempForm
They will see a MODIFY by Distributed Server in their source form
2. Upon MERGE into TempForm, Push Field into MainForm
You will see no MERGE at all for MainForm....BUT...You will see a CREATE
or
MODIFY in MainForm
**except if the MODIFY in step one occurs as a Phase II action, it could
execute close to the RUN Process that you suggest. Hence logging and
$OPERATION$ could be report the wrong thing, which is throwing your
debugging off kilter. Heck, I have seen aspects of the DSO transaction
that occur completely outside of the API, it cannot be detected with
workflow...but it the data is saved.
3. Upon Modify into MainForm DSO on to another server.
You will never see a MERGE by Distributed Server on MainForm...BUT...you
will see a MODIFY by Distributed Server on MainForm
4. Upon Merge on remote server MainForm do nothing.
You will see a MERGE by Distributed Server on remote MainForm...AND...you
will see a MODIFY by Distributed Server on remote MainForm
You will see a MODIFY by Distributed Server on your local MainForm
If your filter is set to execute on Modify and the qual has $OPERATION$
!=
MERGE, and it fired, then your are not in MERGE....so you must be in
Modify.
Before we go any further...which place is the Modify Filter supposed to
Fire; 1,2,3 or 4
Chad
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Frank Caruso
<[EMAIL PROTECTED]
IL.COM>
To
Sent by: "Action arslist@ARSLIST.ORG
Request System
cc
discussion
list(ARSList)"
Subject
<[EMAIL PROTECTED] Re: DSO and $OPERATION$
ORG>
10/17/2006 02:54
PM
Please respond to
[EMAIL PROTECTED]
RG
** Thank you both for your responses ... very interesting reading.
Tony, adding $USER$ would be the easy solution (one I had considered),
however, the transfer-to server is not just a reporting server but it is
also a fail over box. So, all work flow on the box must match production.
Making that type of change would break work flow if we ever failed over.
Chad, your right. Even though the RunProcess set its a MERGE operation, I
don't believe it truly is. I added to the filter RunIf $OPERATE$ != MERGE
and it still ran! I added $USER$!="Distributed Server" and it did not.
However, as mention above, that is not a possible solution.
To make this even more complicated. The DSO transfer is actually being
initiated by a third server in the UK, which then writes to temp table
here, which pushes changes to forms which in turn causes DSO to replicate
data.
Still thinking about it ......
Thank you
On 10/17/06, Tony Worthington <[EMAIL PROTECTED] > wrote:
Frank -
To catch times when this happens -- as mentioned below -- I would say
it
couldn't hurt to add a ( AND $USER$ != "Distributed Server" )
qualification to the workflow in question that you want to make sure is
never triggered by a DSO transaction. This way the workflow will
function
on an import merge, but not a DSO transfer/etc.
--
Tony Worthington
[EMAIL PROTECTED]
262-703-5911
Chad M Whilding < [EMAIL PROTECTED]>
Sent by: "Action Request System discussion list(ARSList)"
<arslist@ARSLIST.ORG>
10/17/2006 01:17 PM
Please respond to
arslist@ARSLIST.ORG
To
arslist@ARSLIST.ORG
cc
Subject
Re: DSO and $OPERATION$
Frank,
If your problem is not intermittent, have you confirmed with logging,or
some other method, that it is actually firing in Merge and not Modify.
In my experience, the DSO transaction on the destination will first
receive
the Merge and then a follow-up Modify. So I am assuming the issue is
on
the destination end, since you mention MERGE.
Even if the Run Process with keywords, is showing Merge, I wouldn't
necessarily trust it, as that is also a Phase III operation and will
fire
the first time Phase III is processed and that could well be the Merge
operation. A Phase III operation doesn't wait until the Phase I or
Phase
II that triggered it completes. A Phase III operation is an
opportunistic
little bugger, they fire as soon as any Phase III is initiated.
All that being said, what does the filter logging show? Any chance
that
you have a MERGE operation that triggers a modify unto the record
itself?
Even via a third form?
Hope this helps
Chad
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient,
please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written
agreement or government initiative expressly permitting the use of
e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Frank Caruso
<[EMAIL PROTECTED]
IL.COM>
To
Sent by: "Action arslist@ARSLIST.ORG
Request System
cc
discussion
list(ARSList)"
Subject
<[EMAIL PROTECTED] DSO and $OPERATION$
ORG>
10/16/2006 10:11
AM
Please respond to
[EMAIL PROTECTED]
RG
ARS 5.01.02 p?????
Sybase on Solaris
DSO
Have a filter that runs on MODIFY only. However, have found instances
where
the filter is running on a MERGE action. So, I added a Run Process
action
to
log to a file when the filter runs and am outputting the following:
$USER$ $SERVER$ $SCHEMA$ $OPERATION$ $Request ID$ $TIMESTAMP$
What I am finding is that the user is Distributed Server and the
Operation
is MERGE, however, the filter is set to fire only on Modify.
Any thought on how this could happen?
Thank you.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
CONFIDENTIALITY NOTICE:
This is a transmission from Kohl's Department Stores, Inc.
and may contain information which is confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution
or
use of the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and
notify us immediately at 262-703-7000.
CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's
reserves the right to retrieve and read any message created, sent and
received. Kohl's reserves the right to monitor messages to or from
authorized Kohl's Associates at any time
without any further consent.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249 __20060125_______________________This posting was submitted
with HTML in it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
--
Frank Caruso
Specific Integration, Inc.
Senior Remedy Engineer
www.specificintegration.com
703-376-1249 __20060125_______________________This posting was submitted
with HTML in it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
