This documentation supports the 9.1 version of Remedy Action Request System.

To view the latest version, select the version from the Product version menu.

Performing distributed operations on join forms

The Distributed Server Option can perform all types of distributed operations — transfer, update, return, and delete — on join forms.

Before performing a distributed operation on a join form, complete these tasks:

  • Add the following field to at least one of the join form's underlying forms:

ARDS_RESERV_DISTRIB_UNIQUE_ID (field ID 322)
  • Add field ID 322 to the join form from one of the underlying forms.
    Field ID 322 is a reserved field that has characteristics similar to field ID 112, the Assignee Group field. A join form can contain only one instance of each reserved field.
  • For CREATE and MERGE operations that trigger DSO actions on join forms, create workflow that populates field ID 322 with the request's joinEntryID before the DSO action occurs.
    The joinEntryID is composed of the request IDs of both underlying forms, separated by a vertical bar (|).
    The system uses the contents of field ID 322 to populate the Source ID field of the Distributed Pending form.

    Note

    Evaluate the workflow to determine whether you need to protect any of the merge filters from the DSO user. If you do, use this qualification: $USER$ != 'Distributed Server'. For more information about the DSO user, see Configuring a password for the DSO user.

  • Create workflow to propagate the distributed data to the underlying forms.


Note

For distributed operations involving join forms, the DSO logs do not include the Request ID of the request created or modified in the target form.

Tip

BMC recommends that you perform distributed operations directly on the underlying forms of a join form instead of on the join form whenever possible.



For more information, see Join forms.

Was this page helpful? Yes No Submitting... Thank you

Comments