...

1. Design option 1: All interfacing via midPoint
2. Design option 2: SoR groups to Grouper

...

Description of data processing

In this section we describe requirements that the overall processing of the data. It is common for both design options have to meet.Basically, we need to . Differences are dealt with later.

Introduction

We need to:

1. fetch data from source systems (represented by a mock of a student information system)

...

1. ,
2. get them into midPoint and Grouper

...

1. where it is augmented and/or modified,
2. provision the data to target systems.

Let's have a look at these componentsthree areas.

Source systems

As a demonstration of source systems let's use the following (extremely simple) three tables:

...

Via midPoint and Grouper we want do achieve the following:

1. We need to be able to modify affiliation information To modify selected information from SoR by including and/or excluding given persons to/from given affiliation groups.
   
   1. This applies to affiliation information: For example we might want to state that although bgasper is listed under alum he should actually not be in alum but in faculty.
   (
   2. Departmental and course information do not need to be changed in this way
   .)
   1. .
2. To create extra groups and manually maintain their members.
3. To create extra groups that aggregate information from other groupsWe need to be able to create specific groups either aggregating information from SoR-based groups or from groups created ad hoc, according to the requirements of the target applications.

In these scenarios we decided to use group-management features of Grouper to implement the above requirements. Therefore, inclusions/exclusions, group aggregation, and ad-hoc group management will be done in Grouper.

Data in midPoint

In midPoint the data is represented like this:

...