• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (1)

1 Brad Konopik commented Permalink

Thanks for the example, Owen. A couple things. your example 101CustomActionPolicy.xml file does not produce the desired result. You end up with 2 separate ACTION_INJECT_TOKEN properties, instead of having those roles appended.

I don't know what that saying "the proof is in the pudding" means, but when crafting custom xml overrides, the "proof" is in the resulting TeamWorksConfiguration.running.xml file (aka: TWCR file) after you restart your server.
I refer back to the example directives I supplied when I co-authored Lombardi Knowledge Library article (now IBM TechNote):
"How to restrict access to ASSIGN type buttons in the Portal"
I used to use a liberal sprinkling of "mergeChildren" directives everywhere, but I stripped this example to the minimum of what worked for me:
(hopefully the HTML-encoded XML will survive .. it took an hour to get it to look correct in "preview" mode)
        <action type="ACTION_INJECT_TOKEN">
          <role merge="append">ROLE01</role>
          <role merge="append">ROLE02</role>
          <role merge="append">ROLE03</role>
Readers: be advised, the mechanism for overrides changed in the BPM 8.5 codeline. Instead of 101MyCustom.xml files the Action Policy overrides use wsadmin scripting as described here:
For BPM 8.5 -- instead of the "pudding" being in the TWCR file, the digested wsadmin directives end up in a file called "cluster-bpm.xml"

Add a Comment Add a Comment