This guide provides information on the different options of outbound integrating with Curriculum. Curriculum is the source that delivers information to the institution ESB. The different integration options are mentioned in a logical order. Based on architectural requirements and available options, a selection can be made from the different options.

For each option a more in-depth explanation is added and if applicable details on the technical implementation.
The options mentioned are:

• Event-based
  Immediate sending by Curriculum of changed objects to the receiving ESB
• Request based: changed data only
  Nightly retrieval of all changed objects including processing via the ESB
• Request-based: full year synchronisation
  Retrieve all Curriculum objects for the still 'editable' years, .e.g. current and next year
• Request-based: full system synchronisation
  Retrieve all Curriculum objects for both all years in the system

To provide a constant up-to-date set of information for the systems using data from Curriculum the advised method is using the Event-based approach by using hooks that will automatically send changed objects reaching a certain status in a process.

The benefit of this approach is:

• all data in receiving systems is always up-to-date
• low impact on resources, since the load is spread over the day
• no long-lasting integration processes by retrieving all data at night

Based on the capabilities of the ESB and your receiving systems this may be an option or noet.

For more details on the configuration of hooks see the generic integration guide.

‍

An approach that can be used in addition to the event-based, but also as a substitution is a regular (e.g. daily) request-based update for only the changed objects.

The benefit of this approach is:

• limited impact on resources, since only changed objects are retrieved and updated using the ESB
• no long-lasting integration processes by retrieving all data at night

Since this is a scheduled job that retrieves data at a regular interval, e.g. daily, the data changed since the last daily update is not 100% up-to-date. By retrieving the last 2 years, this option will keep the receiving systems up-to-date with all changes. If this is no issue for any of the data, this option could be a complete substitution for the first option (event-based).

 The Version endpoint supports the retrieval of all versions (changes) since a specified date-time in the given year. By using a window of ‘last x days’, you can run this nightly and have a standard implemented fallback in case a nightly job fails. The next night the changes for the last x days will be retrieved, including the ones not processed the night before. 

The Version endpoint will result in all changed objects, their version(s) and if they are published.
In case only approved (published) data should be exchanged the approach could be:

• Get all changed objects
  • ‍fromDate: specify a generic date, e.g. now() – 3 days, or use a more intelligent approach by specifying the timestamp of the last successful run.‍
  • year: run twice for the last 2 years.‍
  • page: get the next X if the list is longer than the page size‍
  • size: define the page size (number of records to retrieve per call).
• Determine the objects to process‍
  • dilter the relevant objects, e.g.only published and latest‍
  • date: date of the version, can be used also as option when retrieving last 4 days in combination with last successful run.‍
  • latest: identifies if this is the latest version, or if more versions for this object exist since the given day‍
  • published: identifies if this is the last published version.

Process the objects, which is implementation specific and will use the relevant endpoints, based on the object(s)to process.

‍

Where the first options are focused on only processing changes, there is from an architectural standpoint always a requirement for a full synchronisation of ‘all data’. The full synchronisation will be run on certain intervals, e.g.weekly, bi-weekly, monthly and will retrieve all data in Curriculum for a specified academic-year using the standard API and process the objects via the ESB to the receiving system(s).

 There are no benefits, but it is a required integration pattern, so it must be implemented.

If this would be used instead of the 2 earlier described options, the drawback is that the processing is lengthy (up-to one hour), and takes up quite a lot of resources. Running this at a daily base is probably not the best solution, and should only be done in case the first two options cannot be supported.

The scheduled (e.g. weekly) full year synchronisation should only be used to retrieve the active years, to limit synchronisation to years/data that is still changeable in the system.

The exact setup and required services depend on the system usage. The ‘data’ transmitted requesting information can be steered using the expand parameter. This can be used to limit, or just expand the standard response and limit the number of calls, e.g.:

• ‍?expand=- :the most minimal response ‍
• ?expand=* :the most expanded response‍
• ?expand=group: expand the group information in the response‍
• ?expand=study: expand the study information in the response‍
• ?expand=study,group : expand both the study and group information in the response

The final option is to perform a synchronisation of all data in Curriculum.

If this option is required, it is mostly about ‘recovering all data’ due to a system failure of a downstream system receiving data from Curriculum via the ESB or if there are changes made to years that are no longer editable.

A full synchronisation can be considered a special case of the full year synchronisation where not only the active years are synchronised, but all years in Curriculum. Since the full year synchronisation is just replicated for each required year, the processing time will be equal to the time of a single year times the number of years synchronised.

Based on the assumption this is only run based on incidents, or maybe as a fall-back to synchronise all data every 6 months we would advise the following approach.

• In case synchronisation of all data is required due to an incident or as scheduled (e.g. quarterly) process, use a 2-phased approach
  • synchronise the data really needed, in other words perform the standard full year synchronisation for the active years.
    This one might have run already recently, so this could be an optional action.
  • synchronise the other years (option 3) during a weekend, based on the assumption the historic data is less relevant then the actual data.