SIMS 7 - General Advice - Deep Referencing

Deep Referencing and Partners

SIMS DLLs are strong named. Without some mechanism to ‘redirect’ the call to a suitable replacement DLL in the school’s version of SIMS, there would be a need to rebuild partner applications against each and every version of SIMS released for them to work which is simply impractical.

Our original guidance to partners was to use a manifest file to redirect their API calls to a new version of the DLL. “Generate SIMS Manfiest File”[i] can be used to assist with the generation and is a utility that we provide with each release of SIMS. This mechanism is a pain to use because the manifest file needs to be located in a protected area of the file system and awkward to update especially on terminal servers.

More recently, work derived from initial investigations from the partner team has enabled us to provide a reflection based mechanism for partners as sample code which resolves SIMS Dll calls in one line of additional code [Plus a number of black box code files it wasn’t that simple…].

WARNING

Partners must use the code provided and not use manifest files. Recent development work does not guarantee backward compatibility for deep referencing. Alternative coding models are viable but must not be dependent on a compile time full resolution.

What is Deep Referencing?

Deep referencing is when one SIMS DLL uses another.

SIMS….STUDENT.DLL….PARENT.DLL

If this reference is made when STUDENT.DLL begins life, then any partner application that uses STUDENT.DLL will also know about PARENT.DLL and be quite happy if both or either are updated in a backward compatible way.

If during our development we add a further reference, for example:

SIMS…STUDENT.DLL….PARENT.DLL….CHILDREN.DLL

Or..

SIMS…STUDENT.DLL….PARENT.DLL

         .…CHILDREN.DLL

Then we will have introduced a new deep reference to the Student DLL.

Consequences of additional deep references

The addition of a deep reference will in all likelihood break partner applications that use the manifest file method. We have had examples of failure in the field and the consequence may be serious for the school if for example they cannot use their swipe card access or attendance systems.

We believe, but have yet to prove this, that the reflection technique now offered should work even when deep references are added.

Consequences

• The addition of deep references constitute a breaking change
• Breaking changes embarrass partners, ESS and Schools
• We can make them but need to provide at least a 6 month notice period

Proposed Action                                                     

1. To test out the reflection theory above. (Shown to work internally)
2. Provide a partner update pack to assist partners with the migration to the reflection method on the assumption that it does work
3. Give a 12 month notice period that we will make these changes and explain why [there are often benefits to partner applications from the changes].
4. Require that any breaking deep references changes are undone in the meantime.

[i] Named for understanding.