Custom and canned Action Request Data Location

When a custom action request is created in LTM/GHR, the parameters must be set for the custom form. Does anyone know where the data that is entered into the custom forms live(ex. for position request, description, work schedule, annualhoursper1fte, etc...)? Same question for the data entered into a hire from requisition form. I can see the work unit data for both, but the data in the fields that are populated in the form have not been easy to track down.

Find more posts tagged with

Process Automation (IPA) - General Discussions

Comments

Legacy Contributor

Hi Robert - I had to track down the data from the hire form recently. Some of the data is stored in the JOBAPPLICATION table. We found user defined fields in S$USRA in a pseudo-XML blob field that's difficult/slow to pull from.

+Derek

Legacy Contributor

Hi Robert,

Unfortunately, this is not an easy answer, and it isn't the same for every type of request. Generally, this is stored in the base business class for the Action Request. For example, Hire/Term are Employee actions, so they are in the Employee business class. Position Change, Work Schedule, FTE/Annual hours are WorkAssignment actions, so they are in the WorkAssignment business class. Hires from a requisition are in JobApplication.

However, are you looking for a SQL answer or a Landmark Query answer?

Using a Landmark Query, you can query they base business class using action "Find{Action}" (i.e. "FindHireResource") or "FindMerged{action}" (i.e. FindMergedRehireResource) and passing in the ActionRequest ID (GUID) to return the data from the action request. The difference between "Find" and "FindMerged" is that "Find" only includes the fields populated in the ActionForm, while "FindMerged" will return both the existing values of unchanged fields plus the new values for modified fields in the action form.

If you're looking for a single SQL table where the ActionRequest Form data is stored, you'll never find it. Instead, the information is stored in a CLOB field in a table that is associated with the base business class table for the action. For example, an employee-based Action Request (Hire, Term, etc) is stored as XML data in the S$EMPL table in the EffectiveDatedLog field. WorkAssignment actions are in the S$EMPWA table, etc. The S$xxxx tables are named based on the table prefix for the related table, which can be found in the source code, or by interpreting from the SQL index names on the base table.

Unfortunately, the XML pretty much sucks to work with, and querying from it is completely unsupported by Infor because they can (and do) change the XML schema with application upgrades, and the schemas are not available to the public.

Note that some changes are not ActionRequest based, so they may not work the same way. A good example is Name Change, which is a "State Change" instead of an "Action Request", so different rules apply. It takes some digging to figure out how this all works.

This is very complex and hard to explain for such a broad question, but I hope this is somewhat helpful.

Kelly

rmbell

Thanks guys! Derek, I found one test example in the S$USRA table that I would have never found. Kelly, the info regarding the action requests is very useful, especially the info on the XML schema change potential. What was a SQL question looks like it is becoming a Landmark query solution for consistency.

Copyright © 2025 Infor. All rights reserved.