Josh Holtzman - Mar. 3, 2007

There are two kinds of approaches you can take for bringing your course & enrollment information into sakai via the new CM API. The first is to populate the out-of-the-box hibernate-based implementation using the CourseManagementAdministration API and a quartz job (or something similar). There are already examples of how to do this in the trunk. See the documentation here: https://source.sakaiproject.org/svn/course-management/trunk/xdocs/readme.txt
and some sample reconciliation jobs here:
https://source.sakaiproject.org/svn/course-management/trunk/cm-impl/hibernate-impl/impl/src/java/org/sakaiproject/coursemanagement/impl/job/ .

The second approach is to implement the CM API from scratch against your local data source (Peoplesoft, Colleague, Unidata, etc). At UCB, our SIS folks have built some some nice materialized views in Oracle for us, so we're implementing CM against these views using spring jdbc. You can track our progress in contrib: https://source.sakaiproject.org/contrib/ucb/cm-ucb-impl/ . I think Zhen from U. of Michigan is implementing CM against their local UMIAC system, but I'm not sure where that code lives (or whether it even exists yet ).

There is another way to push data into sakai that has nothing to do with CM. This is the webservices approach that was mentioned earlier in this thread. You create and populate sites directly via webservices, adding members to a course site based on a course's enrollments. But before you go down this path, realize that there are some new features in 2.4 that rely on Sakai's group provider mechanism. If you want to take advantage of automatic section creation and synchronization, you should consider using one of the first two approaches. Manually creating and populating sakai sites directly, avoiding the whole group provider concept, will divorce your sites from any CM-related data such as enrollment status, credits, etc.

> Does a Confluence space make sense for this discussion? A Collab space?

I'd like to see a confluence page that points to different CM implementations. Maybe one space for the "import data into the reference implementation" approach, and another space for those institutions doing custom CM implementations. We could link from these pages to the code that folks store in contrib, and people could ask questions & comment on the different approaches in confluence.

What I don't want to see is a different collab space (and hence, email list) for discussing issues around CM integration. Questions about the UserDirectoryProvider are posed to dev, so I think CM-related questions should remain here, too.

How does that sound?

Josh

Noah Botimer wrote:

> Mike,
>
> My guess is that the most effective strategy might be to define a schema that we can push the data into, and then develop the CM API implementation against that. The providers would then work against an indexed RDBMS instead of files. There could be a stock set of import utils to do that injection from a predefined dump file format and a sample "download program" (as we call them), but I'm hesitant to require people to rewrite those buggers to match the format.
>
> If there are existing downloads that get the needed info in some slightly different format, it might be generally easier to use something like Python or Perl to translate the output into the defined format than rewriting the UniBasic stuff. I also have actually written a generic "importer" tool in Java that takes fixed width and CSV files, and an input spec, optionally operates on the records, then does something with them (taking some action per record, like an INSERT). It's really rough cut, but I could put some cycles on it, if there is no better scriptable tool.
>
> Does a Confluence space make sense for this discussion? A Collab space?
>
> Thanks,
> -Noah
>
>
>
>>>> "Michael Osterman" <ostermmg@whitman.edu> 03/02/07 5:05 PM >>>
>>>>
>
> Perhaps it's time to form a Colleague sub-group. (support group?)
>
> Where would be a good place to coordinate our efforts for Colleague
> implementation of CM-API? I suppose that would also require a standard
> output format from Colleague. I imagine we all have our own ways of getting
> the data out.
>
> Thanks,
> Mike
>
> On 3/2/07, Noah Botimer <njbotime@svsu.edu> wrote:
>
>
>> Mike, Duran,
>>
>> Uncanny... We have, to date, punted on the CM API, too.
>>
>> Just to try to preempt the question, the CM API refers to the Course
>> Management API, where you can implement a set of providers to go get your
>> institutional data upon request. It's necessarily complex to account for
>> the different strategies used across institutions, but it should be possible
>> to find some common ground for Colleague schools and share some code.
>>
>> You can find some nicely detailed docs at:
>> http://bugs.sakaiproject.org/confluence/display/CM/Course+Management+API
>> Thanks,
>> -Noah
>>
>>
>>
>>>>> "Michael Osterman" <ostermmg@whitman.edu> 03/02/07 4:24 PM >>>
>>>>>
>>
>> HI Duran,
>>
>> We're running 2.3.x and colleague R17 on Unidata (soon to be R18 on MS
>> SQL).
>>
>>
>> Our setup is near-identical to SVSU:
>>
>> * Twice daily dumps from Colleague system of all courses
>> * Script finds differences between enrollments for courses that are
>> registered in Sakai
>> * Differences are executed against Sakai server via Web Services
>>
>> We also have a template course and set up courses upon instructor request
>> rather than allowing self-creation.
>>
>> I've got this all documented (including Colleague script) if you're
>> interested.
>>
>> I tried around 2.2.x to integrate with the legacy course management
>> provider
>> but ran into too many problems to achieve our target release date. That's
>> how I ended up with the above solution. I have high hopes for the new CM
>> API
>> and hope to more fully integrate with Sakai by 2.4 or 2.5.
>>
>> Best of luck,
>> Mike
>>
>> On 2/28/07, Goodyear, Duran <DGoodyear@uarts.edu> wrote:
>>
>>
>>> SQL is straight forward enough, but this is a big question.
>>>
>>> We recently deployed Sakai in a test environment, for full campus roll
>>> out in the fall of 2007. (it's the goal).
>>>
>>> But to do that, our biggest hurdle at this point is getting all of our
>>> Datatel Colleague data about classes, rosters, professors, locations,
>>> etc... Inputted in to sakai, in such a way that when students and
>>> faculty login for the very first time, all of their classes and personal
>>> information that pertains to Sakai is preloaded into the system.
>>>
>>> We authenticate against an Active Directory domain, but have all
>>>
>>> This opens a huge can of worms, I'm sure, but this is the first question
>>> in this process.
>>>
>>> Has anyone on this list done anything like this?
>>> Have they done it with Sakai 2.3.x, and Colleague R17 (we're moving to
>>> R18 soon, but that's not my job, thank god).
>>>
>>> What problems have you run into?
>>> What lessons have you learned?
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>>
>>> ] duran goodyear
>>> ] web developer
>>> ] the university of the arts
>>> ] 215.717.6068
>>>
>>> ----------------------
>>> This automatic notification message was sent by Sakai Collab (
>>> https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a.
>>> sakai-dev) site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>
>>
>> [see attachment: "message0.html", size: 2730 bytes]
>>
>>
>> Attachments:
>>
>> message0.html
>>
>> https://collab.sakaiproject.org/access/content/attachment/79afe4e4-66ca-4ff4-8086-d6be299ddb77/message0.html
>> ----------------------
>> This automatic notification message was sent by Sakai Collab (
>> https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a.
>> sakai-dev) site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>>
>>
>>
>
>
> ----------------------
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a. sakai-dev) site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
>