Script Optimization and Self-Healing

Here are some details about the logic behind the visual accessor processing.

About Visual Accessors

  • An accessor is a string that when evaluate finds a browser object.

  • Every accessor has a fallback attribute which mean they will be used as fallback if the global fallback option is enabled.

  • Image accessor are a byImg JS string in the backend.

  • Target is the main accessor, the first element, and only visible in the script UI target is always fallback enabled.

  • Other accessor are called fallback targets and could be used for fallback only if their fallback attribute is enabled.

  • An accessor matches a browser object if, when evaluated it finds the same browser object.

About Self-Healing

  • Self-healing can be run without fallback, however it is not recommended.

  • Self-healing plays the script back once.

  • If the target is valid, it is maintained as the target.

  • If the target is invalid, it is moved to fallback accessors with its fallback attribute enabled and the first fallback accessor found is moved to target.

  • If an accessor fallback attribute is enabled but invalid during the self-heal run, its fallback attribute will be disabled.

  • If an accessor is fallback is disabled and invalid during the self-heal run, it will be deleted.

  • If an accessor is fallback disabled but valid during the self- heal run, its fallback attribute will be enabled.

  • A newly found accessor will be added using the standard approach. Fallback is enabled for all except:

    • index and byXY, due to the brittleness.

    • images as they are expensive targets.

About Optimize

  • The optimize process can be run without fallback, however it is not recommended.

  • In the optimize precess, the target is treated the same as fallback targets.

  • Optimize is based on the success count for each accessor of each step/

  • Each accessor's success count starts at 0.

  • Optimize will run the script five times. Every time an accessor matches the browser object, its success count increases.

  • The maximum success count after the optimize process is 5.

  • At the end of optimize process accessors are sorted first by success count and in the case of a tie in success count then are sorted by these rules:

    Copy 
    array => (/\d\d\d/.test(array) ? 1 : 0),
    array => (/(\d\d)/.test(array) ? 1 : 0)
    array => (/-\d\d/.test(array) ? 1 : 0)
    count('-')
    array => (/\d\d/.test(array) ? 1 : 0)
    array => (/(\d)/.test(array) ? 1 : 0)
    array => (/{.*}/.test(array) ? 1 : 0)
    array => array.length

  • If an accessor success count is 2 or less, then it gets deleted even if it was the target.

  • If a accessor success count is 3 or 4, then it is maintained but with fallback disabled.

  • If an accessor success count is 5. It means it never failed and it is maintained with fallback enabled.

  • A newly found accessor will follow the success count rule. For example the new accessor works 5 times, it is added with fallback on:

    • If it was found only at the end or succeeded only 1 or 2 times it is not added.

    • If it was found and succeeded 3 or 4 times it will be added but with fallback disabled.

    Therefore targets are found only in iterations 1-3, in 4 or five, it makes no sense as there will never get a count of more than 2 successes.

  • Clicking Stop will stop the entire execution not only the current iteration.

If you experience memory errors when executing self-healing or script optimization with visual accessor enabled, first you can try to free up resources on your computer by closing other programs. If the problem persists please consider turning off the visual accessor option.