Custom Java lifecycle modules
A lifecycle is a dm_policy object: named states, plus what runs when an object enters or leaves a state. “Custom Java” here means a method or BOF type you wrote, invoked on attach / promote / demote — not a vendor plugin and not a marketing stack.
What is attached
The SysObject stores the policy id and the current state index:
select r_object_id, object_name, r_policy_id, r_current_state, r_resume_state
from dm_sysobject
where r_object_id = '09xxxxxxx'
select r_object_id, object_name, r_object_type
from dm_policy
where object_name = 'custom_lifecycle'
States live on the policy (repeating attributes: state name, entry criteria, action, post-processing). DA shows them as Draft / Review / Approved or whatever you defined. The integer in r_current_state is the index into that list, not the name.
Where Java actually runs
- A
dm_procedure/dm_methodon the state, executed by the Java Method Server (or Content Server, depending how the method is defined). - A TBO override on the type that implements lifecycle callbacks (same BOF class you might load locally with a registry file in dev).
The method needs a runtime that can see DFC and your jar. If promote “succeeds” in DA but your code never logs, the method is not on that server’s classpath, or the policy is still pointing at an old procedure object.
Attach and move
IAPI sketch (boolean T/F):
fetch,c,09xxxxxxx
attach,c,l,<policy_id>,T
promote,c,l
save,c,l
DFC equivalents: attachPolicy, promote, demote, suspend, resume. Entry criteria that fail abort the promote; they do not leave the object half-moved. Change State extended permission is required to promote/demote; that is not the same as Write. See ACL permissions.
Lifecycle user
Some actions run as the lifecycle owner / a configured lifecycle user, not as the interactive session. If your Java talks to a second system, grant that identity, not only the end user. Do not hard-code customer hostnames in the module.