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 [email protected]
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)"
<[email protected]>
10/17/2006 01:17 PM
Please respond to
[email protected]
To
[email protected]
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 [email protected]
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
