Larry,
Thanks for the details on what your doing. It does help me to
understand what could be going on and to provide a few ideas on how to
troubleshoot this. As far as I know the idea of a "global" (or window
local) field is all in the client layer. I do not believe the server
does anything special with these values between transactions from the
client.
Your statement of "Depending upon which combination" makes me think
you might be fighting more than one logic problem. So, first, let us
break this task down a bit. The beginning looks like "Get Entry" to
me. So let us start there...
I would suggest that you add a filter (on "Get Entry") at execution
order 999 and simply do a set field action that sets every field in
the transaction to it's current value. This will let you log what the
field's values are at that point in the process in your filter logs.
Then I would add enough debug output from your ARSPerl client to also
log all the values (for every field ID) that it gets from the server.
If you detect differences at this point, then we can clearly blame
ARSPerl or the v4 C API. (But I would not expect any differences.)
Now the next thing that is happening is that the ARSPerl client is
"doing something" that either results in a Submit or Modify back to
the AR Server. So again... I would add enough debug output from your
ARSPerl client to also log all the values (for every field ID) that it
sends to the server. ( My guess is that some values are not being
treated as "Global" in the ARSPerl client because it is not keeping
state right, or some other client based issue. Another possibility is
that the v4 idea of "NULL" is not what your sending to the server for
that field. Are you using the perl undef keyword or sending an empty
string("")? But as you say... "Depending upon which combination" of
details, different things might be happening.) Tracking the values
through the client functionality should help you to identify that the
client is doing what you think it should be doing.
Lastly.... I would take that "Get Entry" filter and copy it to a new
filter and make it fire on Submit/Modify at Execution order zero (0).
So that you can check the values that the Client sends to the ARS
server. Again, if you detect differences at this point, then we can
clearly blame ARSPerl or the v4 C API. (But I would not expect any
differences.)
HTH.
--
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 Wed, Mar 19, 2008 at 7:45 AM, L G Robinson <[EMAIL PROTECTED]> wrote:
> Hi Carey,
>
> Thanks for the reply.
>
> Yes, you are correct, by Version 4 API I mean ARSPerl
> built against the version 4 API libs.
>
> Here is what I am trying to accomplish... basically, I
> have written a filter to initialize a global field using
> a "Set Fields" action. The value is read from a parameter
> form. The global field is character and contains a URL
> that will be referenced in various other filters as part of
> a notification system. The filter runs early (Ex order=300)
> to make sure that the value gets set when it is needed and
> it runs on Submit, Modify, Delete and GetEntry, but only
> if the value of the global field is NULL.
>
> Works fine using the WUT. We also have a home-made web
> interface that utilizes ARSPerl. It is when a record is
> access via this web interface that the bizarre behavior
> is observed. The logs show that the filter is being run
> as the record is fetched by the web client, but there is
> nothing unusual in the filter log. I have not looked at
> the API or SQL logs yet.
>
> Depending upon which combination of global and non-global
> fields are set in the filter, some or all of the following
> are observed:
>
> - Some fields on the retrieved record are NULL when they
> actually do have values.
> - Multiple fields on the retrieved record contain the
> value of the global field instead of their correct values.
> - The web client fails doing other (seemingly unrelated)
> tasks such as looking up a group.
>
> Any further thoughts?
>
> Thanks.
> Larry
>
>
>
> On Mar 18, 2008, at 10:20 PM, Carey Matthew Black wrote:
>
> > Larry,
> >
> > I doubt that the "Global field" idea is where the hang up is. I would
> > guess that it is more likely a 'Date' only or 'Time' only, or some
> > other data type before it is a field ID range that is an issue.
> >
> > But in fairness... "some pretty bizarre behavior" is hard to
> > understand too. Can you be any more specific?
> >
> > Since you said v4 api... I am guessing C API? ( Maybe ARS Perl?)
> >
> > You also said.. "workflow in question is in a filter" ... uh.. you
> > mean a run process called from a filter?
> >
> > --
> > 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 Tue, Mar 18, 2008 at 9:01 PM, L G Robinson <[EMAIL PROTECTED]> wrote:
> >> Hi Folks,
> >>
> >> I think I have an API version incompatibility. Can someone
> >> confirm that ARS version 5 was when Global fields were
> >> first introduced? I have check the various documentation
> >> sets and the version 5 set is the first mention of Global
> >> fields that I could find. In version 4, the 1000000-2000000
> >> field id range is described as "Reserved".
> >>
> >> As a followup, I am wondering if anyone can speculate on
> >> what might happen if a version 4 API based client attempted
> >> to access a global field defined under a version 5 API
> >> system. We are seeing some pretty bizarre behavior and I
> >> am trying to convince myself that the API mismatch is at
> >> fault. The workflow in question is in a filter, if that
> >> matters.
> >>
> >> Thanks.
> >> Larry
> >>
> >> -----------------------------------------------------------
> >> L. G. Robinson [EMAIL PROTECTED]
> >> Office of Information Technology
> >> Remedy Services
> >> NC State University 919-515-5432 Voice
> >> Raleigh, NC 27695-7109 919-513-1893 FAX
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
