Technical Tip

Problem

For a customer who happened to be a school, we were having trouble with moving students between the "Active" and "Inactive" container because of how the Student Information System transferred students between schools. Basically, one school would inactive the student, and then another school would active the student. This would generate two events, and if they occurred too close to each other, the student would move to the "inactive" container, but would fail to move back to the "active" container with a "Move in Progress" error.

This alternate method was made possible because in addition to moving the student, the attribute "employeeStatus" was also changed between "A" and "I" for Active and Inactive.

Solution

The solution was to remove all "move" events from the JDBC driver based on the information from Student Information System, and then create two dynamic groups, two Jobs, and a policy.

The two Dynamic Groups were called "ActiveStudents" and "InactiveStudents". The "ActiveStudents" dynamic group watched the "Inactive" container for students with "employeeStatus" equal to "A", while the "InactiveStudents" dynamic group watched the "Active" container for students with "employeeStatus" equal to "I". Basically each group was looking for students in the incorrect context.

The Jobs also called "ActiveStudents" and "InactiveStudents" were set to create trigger events for every member of the dynamic group every hour ("ActiveStudents" on the hour, and "InactiveStudents" on the half hour).

This Policy was then added to the JDBC driver's Subscriber Channel Event Transformation Policy Set, called "MoveStudents":

<?xml version="1.0" encoding="UTF-8"?><policy>

  <rule>
    <description>Move Inactive Student</description>
    <comment xml:space="preserve">If a student is presented by the InactiveStudent job, the Student is in the Active container, but has employeeStatus="I"; therefore, the student is moved to the Inactive container.</comment>
    <conditions>
      <and>
        <if-operation mode="nocase" op="equal">trigger</if-operation>
        <if-op-property mode="nocase" name="source" op="equal">InactiveStudents</if-op-property>
      </and>
    </conditions>
    <actions>
      <do-move-src-object>
        <arg-dn>
          <token-src-dn length="-3" start="0"/>
          <token-text xml:space="preserve">\Inactive</token-text>
        </arg-dn>
      </do-move-src-object>
    </actions>
  </rule>
  
<rule>
    <description>Move Active Student</description>
    <comment xml:space="preserve">If a student is presented by the ActiveStudent job, the student is in the Inactive container, but has employeeStatus="A"; therefore, the student is moved to the Active container.</comment>
    <conditions>
      <and>
        <if-operation mode="nocase" op="equal">trigger</if-operation>
        <if-op-property mode="nocase" name="source" op="equal">ActiveStudents</if-op-property>
      </and>
    </conditions>
    <actions>
      <do-move-src-object>
        <arg-dn>
          <token-src-dn length="-3" start="0"/>
          <token-text xml:space="preserve">\Active</token-text>
        </arg-dn>
      </do-move-src-object>
    </actions>
  </rule>

</policy>

Now if the events come too close together, there is no problem. And if a "Move In Progress" error occurs for whatever reason, there is still no problem - the next time the job runs the Student will be moved. This keeps the students in the correct containers, and it keeps the students and the administrators happy.