Aha, I think I finally understand now, thank you for the help. As you
suggested, using the "Request ID mapping" by doing a prior set fields
lookup does in fact work. However, you might have implied that it would
execute filters that had "get entry" execution-- I still have to enable
"service" for the filter (on FormA). In fact, I can just uncheck Get
Entry if I wanted to, so Get Entry is really only relevant to the filter
execution on FormB now (the one that calls the service action). Also,
not wanting to give up-- I got the other method using input mappings to
work as well which I will describe for posterity. My filter on FormA
required a qualification such as "$department$ = "xxx"" in order to
execute, and the set field fields via SQL action within also used a
"$userid$" field in the SQL statement. So, in order for the service
action to work I had to map both the $department$ and $userid$ fields in
the input mapping table. Yes, that would mean I would have to do a
lookup/set fields for both of these fields before hand, just like you
suggest with the Request ID. So, clearly your suggestion is better in
this case since it is simpler to grab one field versus many.
This does seem fairly simple now-- I was just thinking the input mapping
table somehow was performing a lookup for me. The documentation
seriously understates the difference in using Request ID mapping versus
input mappings, or even a combination of the two. For instance I can
provide both the Request ID Mapping but override certain fields by
setting them in the input mapping table, if I wanted. Pretty cool stuff.
Thanks again!
Brien
On 10/4/2011 1:03 PM, Misi Mladoniczky wrote:
Hi,
I have mostly used services without loading the request, but to be able to
perform the normal filters of the get-entry, you would be required to pass
the Request ID of FormA. In other words, you may need a Set-Fields prior
to the Service-call to retrieve that Request ID.
This should make sure that the FormA-fields are loaded from the database
before your Service-/GetEntry-filter is run.
Finally use the output-mapping to get the results back.
Best Regards - Misi, RRR AB, http://rrr.se
Thank you both for the responses. I've always skipped over the service
action docs thinking it was web services-- I'm trying the service action
first since I don't want to have to modify any records or do any push
fields operations, if I can avoid it. I can't get it to work so far,
though.
FormA: Display only FieldA, Set Fields Filter triggers on Get Entry and
(now) Service. The data is retrieved from SQL command. (this part works
when you are looking at FormA)
FormB: Display only FieldB. Service Action Filter triggers on Get
Entry. Service Action is setup to use FormA as the source. Input
mapping is my join on UserID to retrieve FieldA. Output mapping is the
data returned, FieldA to FieldB. I've tried Request ID: blank and
Request Id: Request ID on the Service Action as well. No difference.
I'm sure I'm missing something because it doesn't seem to do anything at
all. I've tried adding a Set Fields after the Service Action that sets
the field from Current Transaction to be FieldB=FieldB (grasping at
straws). I keep finding references to using Service Action in Active
Links. I'm using Filters only, but the documentation seems to suggest
it doesn't matter.
Thanks for any advice. I will keep looking for some examples too.
Brien
On 10/4/2011 11:30 AM, Misi Mladoniczky wrote:
Hi,
There are three types of operations that gets data I guess.
1. GetEntry in variouse ways, that triggers get-entry-fitlers
2. GetListEntryWithFields and some alternatives that do NOT trigger the
get-entry-filters
3. Internal Filter Set Fields that do NOT trigger the get-entry-filters
In you case, I would suggest that you create a service-call instead,
that
can leverage anything you want on FormA.
Read the Workflo Guide if you are not sure how the Service-action works.
It is really very simple to use.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP
2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
logs.
Find these products, and many free tools and utilities, at
http://rrr.se.
ARS 7.5 P7
I have a form (formA) that sets a field on "Get Entry". This works
great when looking at records or running reports on FormA, even if the
field is display only.
Is there any reason why this filter wouldn't execute from another form
(FormB) performing a Set Fields operation of its own and using FormA as
its data source? Checking Filter logs, the GET event doesn't get
triggered for FormA when FormB is doing its Set Fields operation, so I
don't think this is a phasing or execution order problem. I cannot
find
in the documentation whether this is expected behavior.
A little background, I want to pull in one piece of Customer data from
an external DB (cell phone #) but make sure that it is fresh whenever
it is displayed. So, I have a display only field on FormA that is set
on
Get Entry using a SQL command data source. This works great when
viewing FormA. Now I want to make that visible on FormB. I can't. I
could setup the same DB Set Fields call on FormB, but I would need the
same key fields on that form to do the same SQL command. I could also
bring in the external DB as a view form and join that to FormA and then
go from there, but it seems more complex than it needs to be for just
this one piece of data.
Any ideas?
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
