The SL Call

If a user brings up a form, right clicks in a drillable field, and clicks "Select", an SL call is made to the Drill service. While there are some standard parameters that are passed with this call, there are also a number of parameters that may be included to help narrow the return results. These parameters correspond to a form’s fields that have a "keynbr" attribute defined.

  • An SL call returns a list of either SL calls or OS calls (but not both) to which a user has access.

  • Within Lawson Portal, if an SL call returns an SL call, Lawson Portal automatically calls the Drill Service with the returned SL call.

  • An SL call may return multiple SL calls if multiple select rules exist for a given _KNB parameter value.

  • If multiple SL calls are returned, Lawson Portal automatically calls the Drill Service using the first returned SL call.

The result of this automatic call is a list of records that populate the Drill Around popup window. A single record can be selected, in which case a value (or values) from that record will be used to populated a field (or fields) on the current form. Each of these records has a corresponding OS call which can then be used to drill around.

Using Select in an Empty Form

In the following calls, the _PDL and _RECSTOGET parameters may have different values, depending on the Lawson Environment being accessed and the user's settings.

For example, when you open form AC20.1 in Lawson Portal. The form should be empty. When you right-click the text box for the Activity field and click on "Select". The following call is made to the Drill service:

_TYP=SL&_PDL=APPS810&_SYS=AC&_TKN=AC20.1&_KNB=11P&FT1=&37=&HD2=&37D=
&98A=&98G=&98H=&_RECSTOGET=25

The result of this SL call is a list of records with corresponding OS calls:

In the form definition, the keynbr attribute of the Activity text box has a value of "11P." Thus the _KNB parameter’s value is 11P, indicating that the SELECT is being done on the Activity field. To discover the rule corresponding to this _KNB value is the same two-step process.

For a SELECT, there is one such rule:

DEFINE SELECT

  • ID
  • SCRFLD
  • FILENAME
  • INDEX
  • KEYRNG
  • NXTKEY
  • CONDITION
  • DSPFLDS
  • RETURNS

"Posting Activities"

  • AC-ACV-S-0017
  • POST-TO-ACTIVITY
  • ACACTIVITY
  • ACVSET1
  • @CURSCRFLD
  • POSTING-ACTVTY
  • ACTIVITY:"Activity",
  • DESCRIPTION:"Description",
  • ACTIVITY-GRP:"Activity Group",
  • END-DATE:"End Date"
  • ACTIVITY

The FT1=&37=&HD2=&37D=&98A=&98G=&98H= portion of the query string includes the preceding keynbrs for the Activity text field. All of these parameters are the keynbr attribute values for fields that precede the Activity text field in the form definition. These fields are of different types, including text, hidden, and out. Because none of these fields have values, the keynbr parameters do not have values.

Using Select Call with a Preceding Keynbr Value

  1. Enter a value (e.g., 999) in the text box for Budget Number.

  2. Perform a Select on the Activity text box.

  3. In the debug window, the following call is made to the Drill service:

TYP=SL&_PDL=APPS810&_SYS=AC&_TKN=AC20.1&_KNB=11P&FT1=&37=XYZ&HD2=&37D=&98A=&98G=&98H=&_RECSTOGET=25

This call is nearly identical to the call made when a Select was done with an empty form. The only difference is that the keynbr parameter 37 now has a value: XYZ. It follows then that 37 is the value of the keynbr attribute for the Activity Group text box in the form definition.

Using Select Call with a Following Keynbr Value

  1. Enter a value (e.g., 999) in the text box for Budget Number.

  2. Perform a Select on the Activity text box.

  3. In the debug window, the following call is made to the Drill service:

_TYP=SL&_PDL=APPS810&_SYS=AC&_TKN=AC20.1&_KNB=11P&FT1=&37=XYZ&HD2=&37D=&98A=&98G=&98H=&BU=999&_RECSTOGET=25

This call is nearly identical to the call made when a Select was done with a preceding keynbr value. The only difference is that the keynbr parameter BU has been added with a value of 999. It follows then that BU is the value of the keynbr attribute for the Budget Number text box in the form definition.

Note: Even though the Account Category text box has a keynbr, it is not included because it does not precede the field on which the Select is being done and, unlike the Budget Number text box, it does not have a value.

Drilling from a Select Call

When a user clicks the "Drill" button on the toolbar, Lawson Portal calls the Drill service with the OS call for the first record. The results of this call are then displayed in the Drill Explorer format.

  1. On AC20.1, right click in the text box for the Activity field.

  2. Click Select. The Drill Around popup window comes up with a list of records, each of which has a corresponding OS call.

  3. Click the Drill button.

  4. Click the List button in the toolbar to change back to the record view of the SL call.

Note: The ability to toggle back and forth between List and Drill views depends on which type of call was done first.

Making a select call with user attributes (requires LSF 9.0.1 SP3 or greater)

With LSF 9.0.1 SP3 or greater, Lawson includes support for a new input type that allows for enhanced querying on drill selects. When querying a drill select, you can now specify user attributes and security rules to narrow selection criteria and thus speed up retrieval time

When "@user.attribute" (where "attribute" is a user attribute from a user's profile in security) precedes the rest of a literal in a search string, it means the search will locate records that contain a property from a user record. Following are examples of the syntax used for drill select queries.

Example 1, "old" method: Security rules restrict you to see only employees who report to you.

The value from the POSITION field on your employee record is the value in their SUPERVISOR field. Suppose there are 50,000 employees and 10 of them report to you.

This select returns all the employees in the company:

DEFINE SELECT "Employee - By Supervisor"
ID HR-PTF-S-0070
SCRFLD EMPLOYEE
FILENAME PATHFIND
INDEX PTFSET2
KEYRNG COMPANY-01, "0018"
DSPFLDS FLD-VALUE: "Supervisor", EMPLOYEE, EMPLOYEE.SHORT-NAME
FNDFLDS LAST-NAME, FIRST-NAME, EMPLOYEE.PROCESS-LEVEL,EMPLOYEE.DEPARTMENT,PA-EMPLOYEE.LOCAT-CODE,EMPLOYEE.USER-LEVEL, EMPLOYEE.EMP-STATUS,EMPLOYEE.SUPERVISOR,EMPLOYEE,SALARY-CLASS
RETURNS EMPLOYEE

In this case, the data set contained 50,000 rows, only 10 of which met the criteria and were returned. IOS read 50,000 rows and security denied 49,990 of those rows. This process for retrieving data is very slow.

Example 1, "new" methods: Following are much faster ways to accomplish this query using "@user.attribute" method.

This rule reads the employee record of the current user by taking two values from the user profile, "companies" and "employment."

DEFINE FUNCTION EMP-POSITION()
FILENAME EMPLOYEE
INDEX EMPSET1
KEYRNG

"@user.companies",

"@user.employeenumber"
RETURNS POSITION

By using the function rule that returns the user's POSITION, the following rule reads only those 10 employees whose SUPERVISOR field matches the POSITION field.

DEFINE SELECT "My Direct Reports"
ID HR-PTF-S-L071
SCRFLD EMPLOYEE
FILENAME PATHFIND
INDEX PTFSET2
KEYRNG

COMPANY-01, "0018",

EMP-POSITION()
DSPFLDS FLD-VALUE: "Supervisor", EMPLOYEE, EMPLOYEE.SHORT-NAME
FNDFLDS LAST-NAME, FIRST-NAME, EMPLOYEE.PROCESS-LEVEL,EMPLOYEE.DEPARTMENT,PA-EMPLOYEE.LOCAT-CODE,EMPLOYEE.USER-LEVEL, EMPLOYEE.EMP-STATUS,EMPLOYEE.SUPERVISOR,EMPLOYEE,SALARY-CLASS
RETURNS EMPLOYEE

The following select shows another approach that provides the same results. The rule simply reads a position code directly from the user profile.

DEFINE SELECT "My Reports"
ID HR-PTF-S-L070
SCRFLD EMPLOYEE
FILENAME PATHFIND
INDEX PFSET2
KEYRNG

COMPANY-01, "0018",

"user@positioncode"
DSPFLDS FLD-VALUE:"Supervisor", EMPLOYEE, EMPLOYEE.SHORT-NAME
FNDFLDS LAST-NAME,FIRST-NAME,EMPLOYEE.PROCESS-LEVEL,EMPLOYEE.DEPARTMENT,PA-EMPLOYEE.LOCAT-CODE, EMPLOYEE.USER-LEVEL,EMPLOYEE.EMP-STATUS,EMPLOYEE.SUPERVISOR,EMPLOYEE.SALARY-CLASS
RETURNS EMPLOYEE

Example 2, "old" method: Security allows you to see the twenty employees who work at the three Locations assigned to you. This select shows all the employees in the company.

DEFINE SELECT "Employee - By Location"
ID HR-PTF-S-0067
SCRFLD EMPLOYEE
FILENAME PATHFIND
INDEX PTFSET2
KEYRNG COMPANY-01, "0017"
DSPFLDS FLD-VALUE:"Location", EMPLOYEE, EMPLOYEE.SHORT-NAME
FNDFLDS LAST-NAME,FIRST-NAME,EMPLOYEE.PROCESS-LEVEL,EMPLOYEE.DEPARTMENT,PA-EMPLOYEE.LOCAT-CODE, EMPLOYEE.USER-LEVEL,EMPLOYEE.EMP-STATUS,EMPLOYEE.SUPERVISOR,EMPLOYEE.SALARY-CLASS
RETURNS EMPLOYEE

In this case, the data set contained 50,000 rows, only 20 of which met the criteria and were returned. IOS read 50,000 rows and security denied 49,980 of those rows.

Example 2, "new" method:This select uses a multi-value attribute on the user profile, an attribute capable of holding all the locations assigned to you:

DEFINE SELECT "Employee - My Locations"
ID HR-PTF-S-L067
SCRFLD EMPLOYEE
FILENAME PATHFIND
INDEX PTFSET2
KEYRNG

COMPANY-01, "0017",

"@user.locations"
DSPFLDS FLD-VALUE: "Location", EMPLOYEE, EMPLOYEE.SHORT-NAME
FNDFLDS LAST-NAME,FIRST-NAME,EMPLOYEE.PROCESS-LEVEL,EMPLOYEE.DEPARTMENT,PA-EMPLOYEE.LOCAT-CODE, EMPLOYEE.USER-LEVEL,EMPLOYEE.EMP-STATUS,EMPLOYEE.SUPERVISOR,EMPLOYEE.SALARY-CLASS
RETURNS EMPLOYEE

Only employees whose LOCATION values are in a profile's list of locations are returned.