Hi,

Sometimes you may encounter situations where your colleague developer has checked out rules but he or she cannot check in / discard them for some reasons. In my case, the developer's operator ID was corrupted and he could never log in. Or at other times your colleague may leave the project for unexpected reasons and never come back. With any rules being checked out, you can't lock the ruleset to release it to a production system. In this post, I am sharing how to discard and clean up the checked out rules by other operators.

1. First, identify a checked out rule. In this example, operator "kensho.tsuchihashi" has checked out an activity rule, "MyActivity".

2. Log in to Dev Studio by other operator ID and do "Release lock" from Actions menu on the rule form.

3. At this point, the state of being checked out looks like it's gone. If you want to check out the rule, or lock the ruleset, you can.

4. However, this is not enough. Garbage still remains in the database, and you are advised to clean them up.

4-1. Actual rule table

Identify the physical table for the rule type. There are many derived rules table and you can check it from "Test connection" button on the class form. For example, Rule-Obj-Activity is mapped to pr4_rule. You should be able to locate a rule whose pyruleset value is <OperatorID> + @. In this example, "kensho.tsuchihashi@".

This is the checked out rule. You can delete it and this is the same effect as discard operation.

delete from rules.pr4_rule
where pyrulename = 'MyActivity' and pyruleset = 'kensho.tsuchihashi@'

4-2. Data-Rule-Summary (pr4_rule_vw table)

 When you check out a rule, the state of being checked out is stored in pr4_rule_vw table. This is not cleaned up by "Release lock" operation and should be taken care of manually.

You can delete this record as well.

delete from rules.pr4_rule_vw
where pyrulename = 'MyActivity' and pyruleset = 'kensho.tsuchihashi@'

Hope this helps.

Thanks,