FSM6 u16 Business Rule not matching value

Hi @MartinF,

I believe the issue you're encountering stems from the relationship map jumping from the first table to a second one. While this type of relationship works in substitution maps, it typically doesn't function with standard metadata relationships used in business rules.

To achieve your goal, I recommend creating a view that joins task_event, task, and request. You can then join task_event to this view, which will give you access to req_type for your business rule. Keep in mind that business rules cannot be triggered directly from a view, so it's important to maintain the join between task_event and the view, with task_event remaining as the triggering table.

Also, don’t forget to:

• Add custom metadata for the view.
• Mark the fields used in the business rule as force select.
• Consider limiting the view to only include requests where the status is not 'CO', 'CL', or 'CA'.

Here’s an example of what the view might look like:

!--scriptorstartfragment-->

CREATE VIEW [YourViewName] AS

SELECT

    te.event_sequence,

    te.task_id,

    t.request_id,

    r.req_type,

    r.status

FROM

    task_event te

INNER JOIN

    task t ON te.task_id = t.task_id

INNER JOIN

    request r ON t.request_id = r.request_id

WHERE

    r.status NOT IN ('CO', 'CL', 'CA');!--scriptorendfragment-->

Best Regards,

Morris

Thanks ​@Morris for the detailed explanation. I shall apply that to our solution tomorrow and hopefully resolve the issue.

Hi ​@Morris ,

It didnt work unfortunatetly. I set my view up as described (plus a few extra fields). I set up the metadata for each field in the view similar to below for each field (I set all fields to FORCE SELECT. (Can you explain the purpose of this setting please?)

I also updated the join in the metadata for TASK_EVENT

Finally business rule update

Hi ​@Morris ,

Further to the above, just checking the server log, the first two BR input fields get hit with a match, whereas the 3rd field (from the VIEW - REQ_TYPE) does not even appear.  When i had the mapping to REQUEST, that field from REQUEST was showing in the Log but not matching

Martin

​@MartinF ,

It should be working, when I tested I created the same view and same custom metadata. I setup a business rule using the value from the view. When I execute the rule I can see the evaluation of the input param, and see the result of the test. In my test I am updating the note field on the task. See below I have included a screen shot of the server log entry of the req_type from the view getting evaluating and returning as true.

what are the settings for the custom process for the business rule?

As for the force select option

• Force Select deals with the FSM implementation of Optimistic Record Locking.

• When working with a record, before anything is done, the record is queried.  Values are selected in the query for comparison, a snapshot of those values is made, and the values are kept in memory.  For a pending change, just before committing the database change, only the Force Select fields are re-queried and if there are any differences between the new query and the snapshot query, the Optimistic Record Lock is applied.  If a field changed, the exception: “Row ({table} {table}, (xxxxxx)) was changed after it was selected. Reselect and try again.” occurs, which is known as a “Row Concurrency Error”.  A field that is not designated as Force Select in the new query is automatically assumed to be null, so if the snapshot query has a value, the Row Concurrency Error will occur.

• In general – Set Force Select to Y for any field used in custom metadata, to avoid Row Concurrency Errors.

• More specifically - Set Force Select to Y for any field that may change from business rules, metadata, policies, integrations, imports and external messaging, but not for fields only changed in the smart client, because the screen manager includes all screen fields in its own comparison queries.

Best Regards,

Morris

Hi ​@Morris ,

Thanks for the detailed explanation on Force Select.

Regarding the Business Rule settings. The BR is not attached to a custom process, but onto factory rule 08 (Task Event Notification) Does it have to be on a Custom Process?

Regards,

Martin

Hi ​@Morris,

I just tried setting up a Custom Process but it will not accept any value for the field (REQ_TYPE) for the View??

Am i missing something, somewhere else?

Martin

​@MartinF ,

Please provide screen shots of the custom metadata for the view, including the column defs. Its my guess that there is likely a misspelling somewhere?

Morris

Hi ​@Morris ,

Screenshots as requested

​@Morris 

Would it be anything to do with the table namespace? i just copied the one for TASK_EVENT

Martin

​@MartinF,

I noticed a couple of items that maybe the issue(s).

1.  table namespace and policy name should be blank
2. I don’t see the table script, but it is nice to have so that when you move a package from one environment to the next the, package deployment will build the view for you.
3. based on the error message, it would indicate that the view might not exist in the database. Was the view actually added to the db or did it just get added to the metadata?

4. 

    

5. column defs are incorrect for event_sequence, task_id, request_id

6. 

   

   

   no need to use related column name for the other columns, but I don’t think it will cause any issue.

But first things first make sure that the view has been created in the database, just creating the metadata does not create the view.

Best Regards,

Morris

Hi ​@Morris ,

Apologies for the late reply, i have been off for a few days. Ill check out your suggestions now. The view is definately created in the DB as i can query it.  Is it mandatory to add the table script to the Metadata? I guess not, but it allows the system to automatically add the view during an upgrade if i understand correctly? I will definately add it though.

Regards,

Martin

Hi ​@Morris 

I had some time to look at this today. I have modified the column defs for EVENT_SEQUENCE, TASK_ID and REQUEST_ID as you suggested and removed the Table Name Space and Policy Name, but still no luck unfortunately.

The view definately exists in the DB as i can qery it as below

 Anything else i might be missing here?

Thanks

Martin

​@MartinF ,

Hi Martin,

is there a metadata join between the task event and this new view that you have created, I looks like there is otherwise you should not be able to select that view as an input param. But just wanted to make sure.

Best Regards,

Morris