Banner Relationship Manager Object Installation
NOTE: As of BRM 1.7, Ellucian has created a supported utility for exporting a campaign. See page 15 of the BRM 1.7 Release Notes document for more information. However, the new utility covers campaigns only; if you are working with other objects, you should continue to follow the procedure below.
This document describes the steps for migrating objects from one BRM instance to another. As of this writing, this process is not officially supported by Ellucian.
Sign in via SSH to the TEST BRM application server (at the time of this writing, bcm2.dev.oakland.edu).
Become the oracle user.
- Set the BRM environment to that of the source BRM instance:
. brmenv (be careful to enter the period and space before the brmenv command, as shown)
- Enter the database SID of the BRM instance.
- Navigate to the bin directory for the source BRM instance:
cd $BRM_HOME/bin
- Obtain the relate_root_user password:
grep relate_root_user $BRM_HOME/instance/config/*
Create a full export of the BRM objects. The suggested format for your export file name is full_export_YYYYMMDD.xml, where YYYYMMDD is the current date:
./export relate_root_user relate_root_user_password full_export_YYYYMMDD.xml -xml (again, be sure to type the opening period and slash as shown)
- If there are any errors during the export, check the Ellucian Support Center for an appropriate solution and attempt to resolve it; then try the export again.
- Open the resulting export file in a text editor.
- Manually select the lines pertaining to the objects you wish to migrate, and copy them to a new file, which will be your import file. There is no extract function as there is for Banner Workflow; therefore, you must be careful to select all the lines needed to define the new object, including the definitions of any dependencies. There does not seem to be ONE intuitive way to identify dependencies, so examine the following tags within the definition of the object you are extracting (this may not be an exhaustive list) to find other objects that it is dependent on:
A <urn:RuleUri> tag in a campaign will identify any rule objects needed; these are marked by a <urn:Rule> tag.
A <urn:Rule> tag will have a matching rule set object with a <urn:RuleSet> tag; these must also be copied.
A <urn:Rule> tag will also have a matching rule set URI object with a <urn:UriRuleSetMap> tag; these must also be copied.
A <urn:RuleSet> definition will reference one or more rules, indicated by <urn:RuleName> tags. If a rule is referenced but was not copied using one of the steps above, copy it as part of this step.
Any tag that ends with "ref", e.g: <urn:population-named-ref>, <urn:role-named-ref>, &c, will identify a dependency that may be needed; the ones we've encountered so far are enumerated below.
A <urn:communication-template-named-ref> will have dependencies on a <urn:Folder> item, a <urn:CommunicationTemplate> item, and one or more <urn:CommunicationTemplateVersion> items; and the <urn:CommunicationTemplate> item will have a further dependency on a <urn:Organization> item, as well as an <Owner> which needs to exist in the target system as a user. Proposed: if the owner is not a user in the target system, reassign the owner to be the ID of the person who requested the migration.
A <urn:CommunicationTemplateVersion> item may refer to one or more <urn:CommunicationField> items. These are not always easy to spot; they may appear in any of the tags of the CommunicationTemplateVersion definition, and will be delimited by "|::" and "::|" (for example, "|::=Constituent.Contact Information.Email Address::|"). There are three components to the CommunicationField item, delimited by "." In the given example, there will be a <urn:!CRMEntity> item named "Constituent", a <urn:FieldSet> item named "Contact Information", and a <urn:CommunicationField> item named "Email Address"; all three of these will need to be copied. Note that a CommunicationField item may also have a <urn:RuleUri> tag, and you will need to include the Rule, RuleSet, and UriRuleSetMap items as described above. (For CommuicationFields, it may be easier to let the import process find any missing dependencies: attempt to import your import file and note any "UnknownFieldException" errors; use these errors to identify the CommunicationFields to be imported.)
Save the import file with an appropriate unique name. The suggested format for the name is ticket_uts_NNNNNN.xml, where NNNNNN is a 6 digit number (left-padded with zeroes) representing the ticket number of the migration request, and uts is the Helpdesk project name or ticketing system identifier (in case a new project or system are ever selected).
Sign in via SSH to the TEST BRM application server (at the time of this writing: bcm1.sys.oakland.edu).
Become the oracle user.
- Set the BRM environment to that of the target BRM instance:
. brmenv (be careful to enter the period and space before the brmenv command, as shown)
- Enter the database SID of the target BRM instance.
- Navigate to the bin directory for the target BRM instance:
cd $BRM_HOME/bin
- Obtain the relate_root_user password:
grep relate_root_user $BRM_HOME/instance/config/*
- Move the import file from the source BRM bin to the target BRM bin:
if on the same server: mv ../../source_sid/bin/ticket_uts_NNNNNN.xml .
if on a different server: scp -p source_server:source_dir/ticket_uts_NNNNNN.xml .
- Import the import file:
./import relate_root_user relate_root_user_password ticket_uts_NNNNNN.xml
- If any errors are encountered, take appropriate steps to correct them:
- You may be able to simply recreate your import file and try again.
- If objects that you imported successfully are incorrect, you may need to sign into the target BRM instance and delete them before retrying.
- In the absolute worst case, you may need to open a contact with Ellucian, but bear in mind that this process is not supported as you are framing your request for assistance.
DataAdminHowTo
DB_Administration