Community

Connect with us and enhance your M-Files experience using Unitfly Toolkit for M-Files. Here’s how to get started.

Notifications
Clear all

[Solved] Property operation, rule not registrered

0
Topic starter

Have a bunch of rules (69) configured, most of them work just fine. However, the latest rule does not get registered in the log nor does it trigger when required.

Logging is active on Information level. This way there should be a log entry whenever you change a rule configuration, and that is the case for the working rules.
Nothing is recorded on the latest rule. It has one error related to the use of {.} (self) in a property setter, but that should be OK even though it is annoying.
Other than that I cannot see what might be wrong and why changes are not logged.
The trigger does not work either. It could be misconfigured, but I have checked it over and over again and compared it to working rules. Cannot see anything wrong.

Is there a limit to how many rules one can configure in one module (like a max size of the JSON configuration file)?
If not, what else might be wrong?

{
    "Name": "Håndværkerliste find sag, ny",
    "ConfigurationMode": "Advanced",
    "Trigger": "ObjectEnteredState",
    "CopyMode": "OnSourceObject",
    "Source": {
        "ObjType": "{53F0C8FD-0BF0-47C4-8FA6-4C2D0DADB650}",
        "Class": "CL.IndkbsordrerAab",
        "Workflow": "WF.IndkbsordrerAbb",
        "State": "WFS.IndkbsordrerAab.B1bTilfjSagArtesa",
        "SearchConditionFilters": [
            {
                "SearchConditions": [
                    {
                        "conditionType": "equal",
                        "expression": {
                            "type": "propertyValue",
                            "propertyDef": "PD.SagArtesa",
                            "indirectionLevels": []
                        },
                        "typedValue": {
                            "dataType": "lookup",
                            "value": {
                                "isNull": true
                            }
                        }
                    }
                ]
            }
        ]
    },
    "VaultSearchFilters": [
        {
            "StatusFieldConditions": [
                {
                    "Field": "Type",
                    "ValueType": "Static",
                    "ObjectTypeValue": "OT.SagArtesa"
                }
            ],
            "Conditions": [
                {
                    "Property": "PD.Leveringsoplysninger",
                    "Operator": "MFConditionTypeContains",
                    "Value": {
                        "Mode": "Dynamic",
                        "DynamicValue": "%PROPERTY_{PD.Lejeml}%"
                    }
                }
            ]
        }
    ],
    "Properties": [
        {
            "Property": "PD.SagArtesa",
            "ValueFrom": "VaultSearch",
            "Value": {
                "Mode": "Dynamic",
                "DynamicValue": "%.%"
            },
            "Additional": true,
            "Update": "OnlyWhenTargetEmpty"
        }
    ],
    "PropertyErrorHandlingBehaviour": "Continue",
    "ErrorHandlingBehaviour": "Continue",
    "Description": "Der kommer en fejlmelding vedr. placeholder {.} i /Properties/0/Value/DynamicValue. \nDen skal blot ignoreres. Det virker, som det er!"
}
Karl Lausten Topic starter 28/03/2024 10:48 am

Had a chance to test while noone else was active on the vault. This revealed that a different rule was triggered when something changed on documents matching this rule. That seems rather weird given that the other rule was set with a different Class as source and with search filters not matching the documents used as source in this rule. The insight made me configure the other rule with more specific trigger settings to prevent it from running when not needed. However, the current rule still does not trigger - not even when I change the trigger to Object metadata changed, monitoring a specific boolean property and then manually change the value of that property. Have also tried to remove Class, Workflow, State and SearchConditionFilters hoping to be able to trigger the rule. No luck!
Have also removed a couple of Run once rules that were no longer needed in an attempt to reduce the size of configuration. Have tried to change the property setter to avoid the Self reference and thereby remove the "error" message. Nothing will make this rule trigger. 

Any ideas?

Karl Lausten Topic starter 03/04/2024 3:42 pm

Not directly related to the above issue but even so:
When using regex to extract a string from content with external origin the string may sometimes come with upper or lowercase characters that case-wise do not match the content found in M-Files. When using the "contains" operator in a search it appears that the search is case sensitive. So, if I extract "s-24-9876" from external data and use this string to search for a case that has "S-24-9876" in its name, then the search will fail.
Is there a way to make the "Contains" operator case-insensitive?

In this particular situation I solved the problem taking the initial "s" out of the search string and only use "-24-9876". It works here but might not be a feasible workaround elsewhere.

Tadej Šetinc 04/04/2024 2:09 pm

Hi @karl-lausten,

 

Currently this is not possible, and I don't have a better solution for you from yours at the moment.
 

Regards,

Tadej

2 Answers
0
Topic starter

Hi Tadej,

Thanks for the feed back. Yes, adding a Vault sort configuration helps. However, it also seems to make the process very slow. In my case the list contains about 25.000 objects. If the module attempts to sort all of them before searching that would explain the time consumption. If search is done first, then sorting should not take long - there would only be one item to sort 😉 

Best regards, Karl

Tadej Šetinc 04/04/2024 1:59 pm

Hi @karl-lausten,

 

The problem is in the operators used in the vault search conditions. Contains is actually our custom operator, because Contains from the M-Files can work only with the text-based properties.

So because of using custom conditions, we actually need to do 2 rounds of search in your case.
1. Is search by object type - And this will find all 25.000 object in your case..
2. And the second is then using Contains operator - and this needs to go through all the objects, and that is why is so slow.

So the solution here would be, to improve your search with some additional conditions, using standard operators (=, !=, >, <, etc.), if that is possible of course..
If that is not possible, then I would suggest using Specify search in the property setter instead of vault search, I can't guarantee for sure, but I believe this would be faster.

image

 

Regards,

Tadej

Karl Lausten Topic starter 04/04/2024 3:27 pm

Thank you. Adding an additional condition using "=" as operator narrowed the number of items for the Contains operator down to just a few hundred, and response time was reduced to and acceptable level. 😀 

0

Hi @karl-lausten,

 

We tested your use case, and I believe we found an issue with a vault search, but before fixing this, we need to discuss it internally. So I would say that your rule configuration is good, and there is no issue with too many rules or something like that.

 

Till we don't decide what to do about this, I can suggest you a workaround that worked for me.

To your rule configuration just add some basic Vault search sort, something like shown in the image below, and test it.

image

 

And please let me know if this works for you too.

 

Kind regards,

Tadej

Answer