IPA process flow to delete completed action requests and move completed work units to history

Hi SAres,

Wow - that's an ambitous task to start with. However, it's not hugely difficult.

IPA will allow you to do (almost) anything you can do via the Rich Client application - and many things that you can't. I'd recommend starting by figuring out exactly how you would do these tasks manually in Rich Client - documenting the steps. This will basically become a spec document for your development.

In IPA, I'd do something like this to delete completed ActionRequests:
- go to Data Menu >> {prodline} >> la >> Business Classes >> Action Request
- Filter on XXXXX to identify completed action requests (maybe IsOpen=false and Status=Complete)?
- select record and click Actions>>Delete

Based on this, in IPA I would do this:
- Build a Landmark Query:
- Module=la
- ObjectName=ActionRequest
- Action=Find
- ActionType=MultipleRecordQuery
- Selected Fields: ActionRequest, IsOpen, Status, ????
- You can then either use a filter in the query, or just branch based on the returned data (I'm not a big fan of the filter functionality).
- Test with that query until you are sure it is returning the correct data.
- Within that node loop, then I'd add another Landmark query
- Module=la
- ObjectName=ActionRequest
- Action=DeleteNotInProcess
- ActionType=CreateUpdateDelete
- Selected Fields: ActionRequest={first query}_ActionRequest

I'd probably set the second query to use Custom Error Routing and log the errors into a file (using the FileAction node), and then email the file to myself at the end of the flow run.

etc.


Finally, a warning - make sure you are aware of the impact of this before you jump in and start making these types of updates. Many of them are not reversable - at least not without doing SQL updates, which are difficult.

I hope this is helpful. Good Luck!

By the way, you didn't mention if you have LSF/PFI experience, but there is one significant difference between LSF and Landmark. In Landmark/TM, the Actions and WorkUnits are stored in the application productline rather than the environment productline (GEN).

I think the Landmark Transaction has a MoveWorkUnitToHistory function.

Like David said, there's a MoveWorkUnitToHistory action in the LM node. Module = pfi, prob use the set ByStartDateWorkunitLive and build criteria to move to history off the EndDate.

We archive daily, for workunits that have an end date > 15 days old.

Thank you for all the responses. I appreciate the detail Kelly went into explaining the Rich Client logic vs. process flow logic. I am aware the work units are part of each data environment with Landmark. I have done some process flows with LSF. Soon I will ba tasked with converting all the LSF 9.X flows to Landmark 10.X as we upgrade LSF and shut down the old process flow server. I'm sure I will be back on here when that project start unfolding.

Thanks again.

I did get something to work for both the action requests and work units but I fear that as the number of workunits increases, I will encounter issues. For both the action requests and work units, I have a Landmark Transaction node to find the records then for each record, I process a delete on action requests and a move to history on work units.

The transaction node that finds the records is returning too many results.

I narrowed the results of the action requests to those where the delte flag is zero (not deleted) and the status is 9 (completed). It is returning all action requests where the delete flag is zero but ignoring the status.
Landmark:FindCompletedRequests Executing transaction_dataArea="" & _module="la" & _objectName="ActionRequest" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _pageSize="30" & ActionRequest_DeleteFlag="0" & Status="9" & ActionRequest

I narrowed the results of the work units to those where archived is zero (not already in history) and the status is 4 (completed). It is returning all work units and ignoring the status and archived field requirements. As a result, the entire set of work units go through the delete mode.
Landmark:FindWorkUnits Executing transaction_dataArea="" & _module="pfi" & _objectName="PfiWorkunit" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _pageSize="30" & Status="4" & Archived="0" & PfiWorkunit

Any ideas?

SAres - are you using a SQL query to identify the records? If not, then you shouldn't have to reference the delete flag at all, because the Landmark query should only return non-deleted records in any case. Since Status isn't a key, you probably need to do it as a filter rather than a direct data selection.

Try this instead for ActionRequests: 
_dataArea="prodhcm" & _module="la" & _objectName="ActionRequest" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _runAsUser="" & _pageSize=30 & _filterString=Status="9" & ActionRequest & Status
  
And try this for WorkUnits: 
 _dataArea="prodhcm" & _module="pfi" & _objectName="PfiWorkunit" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _runAsUser="" & _pageSize=30 & _filterString=!Archived and Status="4" & PfiWorkunit & Status & Archived

Kelly,

Using the filter option worked perfectly. I am using a Landmark node not a SQL node. So I guess the rule is, explicite declarations on key fields and filter strings on non-key fields.

Thanks again

Yep, that is correct. Just a warning that filters can cause huge performance issues - mostly filters on derived or related fields.

For example, we had a flow that was filtering on Employee.AgentEmployee in order to use an ActorID to find the related employee. This was causing our CPU to spike and the flow to "stall" for over 10 minutes while the filter processed, because it has to load and evaluate every record. In this case, I replaced the Landmark query with a SQL query that returned similar data in a fraction of a second. The only trick is eliminating deleted records from the SQL query, etc.

Using the standard Lawson commands to move the completed work units to history works fine.  In addition, as the format between current and history is the same all potential reports can be easily written.  Crystal Reports works fine with two subreports (current and history).

Could not figure out how to post a new question so I thought I would enter my question here.

We are converting our PFI to LPA and some of your processes first check that the service is not already running or failed before it starts. I have converted them to Landmark transaction nodes and tested them they work but I still have the red X in designer.

Here is the landmark transaction I am using.

_dataArea="focusdev" & _module="pfi" & _objectName="PfiWorkunit" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _pageSize="30" & _filterString="IsCanceled" & IsCanceled="true" & PfiWorkunit

complete: true
response message: null
record count: 2
has next: false
has previous: false
Results header string: PfiWorkunit
Results string: 23
24

Communications trace
null

This is the error message for the X. "Conversion issue exists, please verify and fix"

Is there really an error our do I just have to mark it as fixed?

Your query syntax could be correct but something else, like the debugging options, might not be complete and you would still see the red X signifying a problem.

When I run this in LPA I receive the following error in the logs. Unable to create local execution container for focusdev-com.lawson.apps.null.null

Hi amylynanderson,

I'm not sure if these are related to the error, but here are a couple of things to check:
- Is "focusdev" the correct productline? Note that in IPA the productline is NOT gen (environment) but is the application productline.
- You have both "filterstring="IsCancelled"" and "IsCancelled="true"". You shouldn't need both, and the filter is probably a better option since "IsCancelled" is not a key. Also, I've found that sometimes for boolean values I have to filter for 1/0 rather than true/false. I'd suggest that you try different combinations and see if you can get it to work.

Good Luck!

By the way, to create a new thread, just go to the forum you wish to post to (in this case https://www.lawsonguru.co...tion/lawson-pflow/), and right at the top (under the forum title) and at the bottom (under the last thread on the page) are "Add New Topic" buttons.
Are you getting this error in Designer or on the server? If it's in Designer it is much easier to test. It should work the same in both places, but that isn't always the case.

I did correct the query and in designer I am getting results just not in LPA

This is my results and I have verified the data coming back is correct.

complete: true
response message: null
record count: 10
has next: false
has previous: false
Results header string: PfiWorkunit
Results string: 9
10
11
14
16
20
21
26
27
28

Communications trace
null

I think it has to do with my system configuration but is all that is there for LMK is main and focusdev   There is no external connection so nothing else needs to be filled in.