Sorry for the late post on this topic
 
Perhaps an example may help...  If anyone wants an example like this
that you can import and play with, let me know and I'll drop something
on BMCDN
 
/* Preamble */ 
On how many forms do you have workflow that performs a function like
checking to see if an entry already exists? That's X forms with Y amount
of workflow actions (filters, active links, or both). Each form's
workflow to manage that has essentially a rigid definition of the
criteria of that lookup in the set field from server action, meaning
there's not much of an opportunity to used shared workflow across all
the forms (at least without creating unnecessary mess on those forms). 
 
Using the service action you can do this cleanly across all forms and
have it work with both filters and active links (cutting your code
footprint). Here's quick rundown of what that 'could' look like: 
 
/* For the service action, there is a client call (where the service
call is made by filter or active link of a form) and a "server" call (or
where the call is "handled" on some form)
    The following is the "server" end of the transaction processing. 
*/
 
1. New Display Only Form (let's call it XYZ:SVCBUS)
2. Add necessary fields to that form
    - Add a half dozen or so of each relevant field type (int, char,
etc) for input and output 
    - Add a char field - call it serviceAction [this is where you
distinguish what workflow will fire for the various service calls- just
one approach]
    - Add a char field - call it zzTbl_Qual - we'll use this later in
the example
    - Add other temp fields as necessary to process service actions
        - Since we're working on the "does it exist" example, create a
table field with generic properties: 
            a. Data Source = SAMPLE DATA
            b. Sample Form Name = <pick an existing regular form...
doesn't really matter>
            c. Runtime Server Value = $SERVER$  //the current server
            d. Runtime Form Value = $input_map_field01$  //we'll pass
this in with the service call
            e. Qualification = EXTERNAL($zzTbl_Qual$ AND $zzTbl_Qual$ !=
" ")
            f. Add single column to the table (this should be the field
with database id = 1, whether that's Entry-Id, Request Id, or whatever
it may be called) 
 
3. Define filter to process service action
        a. Filter Name: XYZ:SBUS:GDE_Service_LookupByQual_Process 
        b. Execution Options: State = Enabled, Execution Order = 0, (no
actions checked)
        c. Run If Qualification = ('input_map_field00' != $NULL$) AND
('input_map_field01' != $NULL$)       
        d. Error Handler = <you can have a error handler filter set an
error code/message to one of the output fields if you desire>
        e. If Actions:
                SetFields 1: Set (current transaction) 'zzTbl_Qual' with
'input_map_field00'  //sets table qual with the qual we received from
input map
                SetFields 2: Set (current transaction) 'out_map_field00'
with COLCOUNT(the_the_column_from_the_table_field)
 
/* If you start accepting many different service calls with many
different operations the guide approach helps for clarity 
    a bit bulky in this minimalist example
*/                               
4. Define a filter guide for form XYZ:SVCBUS
        a. Application List Label = LOOKUP_CHECKEXISTSBYQUAL
        b. Description:   This function is used whenever it's necessary
to look to see if a record already exists in some form. 
                                This is typically used in validation
checks especially for duplicate entries
        c. Guide Name: XYZ:SBUS:Lookup_CheckExistsByQual
 
5. Define your service filter to accept service calls for form
XYZ:SVCBUS
        a. Filter Name: XYZ:SBUS:SVC_LookupByQual_CallGDE
        b. Execution Options: State = Enabled, Execution Order = 500
<adjust as needed>, Service = Checked
        c. Run If Qualification = 'serviceAction" =
"LOOKUP_CHECKEXISTSBYQUAL"
        d. Error Handler = <you can have a error handler filter set an
error code/message to one of the output fields if you desire>
        e. If Actions = Call Guide -> XYZ:SBUS:Lookup_CheckExistsByQual
 
/* For the service action, there is a client call (where the service
call is made) and a "server" call (or where the call is "handled")
    The following is the "client" end of the transaction processing. On
the example form below we'll just flag a service call by gaining
    focus on the Status field and setting a field with a value returned
from the service call. The value returned is this case is the number of
    records that match the qual we pass in. 
*/
 
1. Create new regular form (let's call it _Example1)
    a. Add a new char field call "My Field"
 
2. Create an active link (or you could do it with a filter)
    a. Name: _Example:Service_IsExisting
    b. attach it to the new form created
    c. Execution Options: Gain Focus on Status field
    d. If Action -> Service
        - Form Name: XYZ:SVCBUS
        - Request Id = Request Id
        - Input Mapping: 
                'input_map_field00' -> "1=1"  (//just hardcoding
something here for now, but ideally this should be dynamically set)
                'input_map_field01' -> "User" (//just hardcoding
something here for now, but ideally this should be dynamically set)
                'serviceAction' -> "LOOKUP_CHECKEXISTSBYQUAL"
        - Output Mapping: 
                'My Field' -> 'out_map_field00' 
 
Kind Regards, 
 
Eric Roys
System Analyst/Programmer
Information Technology
Verizon Business
eric <dot> roys@verizonbusiness <dot> com
<mailto:ericr...@verizonbusiness.com> 
        
________________________________

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Friday, April 22, 2011 2:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Service Action Type


** 

Abdelaziz,

If you are familiar with standard OO Programming, you know about
methods.  A method accepts x inputs, and provides y outputs.  Think of
the service action in the same light.  Build up a series of filters that
do a function you need done, have them fire on the 'Service' event.
Then build an AL that calls a service action and provides the necessary
inputs, and maps the outputs to where you need.

 

Viola, you have a service action.  Think of it as a way to create code
modules that can be called repeatedly throughout your application and
always provide the right input, always getting the right output.

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Mohamed Abdelaziz
Sent: Friday, April 22, 2011 11:13 AM
To: arslist@ARSLIST.ORG
Subject: Service Action Type

 

** 

Can you please provide a detailed definition with scenarios on the user
of Service Action Type. (I. E. The use of input mappings, output mapping
and Request ID) The user guide does not seem to provide a clear and
detailed definition. 

 

Thanks,

Moe

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 

_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"

Reply via email to