https://docs.moodle.org/310/en/api.php?action=feedcontributions&feedformat=atom&user=WoolardfaMoodleDocs - User contributions [en]2026-06-26T01:41:10ZUser contributionsMediaWiki 1.43.5https://docs.moodle.org/310/en/index.php?title=Filters/rtmp&diff=116187Filters/rtmp2014-12-01T15:12:01Z<p>Woolardfa: </p>
<hr />
<div>The '''RTMP streaming media filter''' is used to replace links containing URLs beginning with rtmp:// with a Flowplayer media player using their [http://flash.flowplayer.org/plugins/streaming/rtmp.html rtmp plugin]. It is contributed by [http://moodle.org/user/view.php?id=286444 Lacey Vickery] and [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Page output is examined for anchor href values beginning with rtmp:// and ending with a supported extension (currently .mp3, .mp4, .flv,, .f4v, and .mov). Qualifying links are replaced with a span tag containing 'data-' prefixed attributes that are subsequently used by the plugin's JavaScript module to apply a Flowplayer player to the span. The Adobe Flash Player browser plugin is required.<br />
<br />
The plugin was developed to work with Adobe's Flash Media Server, but according to Flowplayer, their [http://flash.flowplayer.org/plugins/streaming/rtmp.html RTMP plugin] should work with Wowza, and Red5 as well. The plugin has been tested successfully with Amazon's Cloudfront streaming service.<br />
<br />
=Installation=<br />
* Select the correct version of the filter_rtmp.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the '''filter/''' folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
* Enable and configure the plugin (Site administration->Plugins->Filters->Manage filters).<br />
<br />
=How to use=<br />
In places where you can enter HTML (e.g. wysiwyg editor for topic summary, page resource, etc.), create a link and supply a URL that references the media stream you want to play. The URL would look something like: ''rtmp://fms.example.org/vod/classes/lecture01.flv''<br />
<br />
The file extensions filtered are: '''.flv, .mp4, .f4v, .mov, and .mp3'''<br />
<br />
==Cloudfront Streams==<br />
Amazon's Cloudfront streaming requires the Flowplayer config values for netConnectionUrl, and the clip's URL to be slightly different. For streams originating at Cloudfront append the following query string paramter to the URL so the filter will adjust accordingly: '''?provider=acf'''<br />
<br />
=Playlists (v1.3)=<br />
Support for playlists has been added. Refer to the [[Playlist plugin]] docs.<br />
<br />
=Closed Captions (v1.4)=<br />
Support for closed captioning has been added. The filter can optionally load Flowplayer's [http://flash.flowplayer.org/plugins/flash/captions.html Captions] and [http://flash.flowplayer.org/plugins/flash/content.html Content] Flash plugins (.swf) to display closed captioning in the media player window. Even though Flowplayer's Caption plugin can load an external file containing the caption information, the filter does not yet provide for this method. The caption information must be embedded into the media file, such as an MP4 subtitles track, or FLV cuepoints.<br />
<br />
The filter has an additional site config to determine whether or not to load the Caption plugin by default. To override that default append the following query strting parameter to the URL: ''''?captions=1'''', or ''''captions=0'''', to load or not load the Captions plugin, respectively. These query string parameters are detected in playlists, so you can be selective about which clips in a playlist display closed captions.<br />
<br />
=HLS from Wowza & FMS (v1.5)=<br />
Support for HTML5 video and audio has been added. Wowza's Streaming Engine and Adobe's Flash Media Server each support (after some configuration) Apple's HLS to allow delivery to iOS devices. The filter can detect whether the Flash plugin is present in the browser, and if configured to do so, will emit primitive HTML5 <video> and <audio> tags with source URLs corresponding to the Wowza/FMS HLS stream.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=filter_rtmp here].<br />
<br />
=Source code=<br />
The source code repository is located at github.com in the [http://github.com/appalachianstate/moodle-filter_rtmp appalachianstate/moodle-filter_rtmp] repository.<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=SHEBanG_plugin&diff=114145SHEBanG plugin2014-08-13T14:17:06Z<p>Woolardfa: </p>
<hr />
<div>==SHEBanG enrolment plugin/module for Banner(r) LMB data import.==<br />
<br />
This enrollment plugin provides a way for Moodle to consume Banner® LMB (Luminis Message Broker) messages. This module is not an Ellucian product, and is neither endorsed nor supported by Ellucian. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Messages are POSTed by LMB to a configured target URL; that URL should end up resolving to $CFG->wwwroot/enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias; aliases will not work from Moodle 2.6 and later). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrolment plugin, [https://moodle.org/plugins/view.php?plugin=enrol_lmb, LMB (enrol_lmb)] developed by [https://moodle.org/user/profile.php?id=139623, Eric Merrill] that processes Banner data, and has many more configuration options and features. We used Eric's plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installation of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
'''THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.'''<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin and shared with the Luminis admins.<br />
<br />
===Using Oracle===<br />
If Oracle is being used, the NLS_DATE_FORMAT session setting has to be adjusted from the default. SHEBanG expects it to be set to 'YYYY-MM-DD HH24:MI:SS', but if that is not practical for your installation (conflicts with other plugins, etc.) then the format used by SHEBanG can be changed in the lib.php (DATEFMT_SQL_VALUE).<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
In versions for Moodle 2.x, an option was added allowing selection of what is placed in the [mdl_user](idnumber) column--either the SCTID value, or the Luminis Id value. The referenced [mdl_user](id) column value is now placed in the [enrol_shebang_person] table.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [https://moodle.org/plugins/view.php?plugin=enrol_shebang here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=admin/setting/filtersettingrtmp&diff=111190admin/setting/filtersettingrtmp2014-03-19T14:23:02Z<p>Woolardfa: </p>
<hr />
<div>==General==<br />
'''Filter audio (.mp3)'''<br />
<br />
Enables/disables filtering for streamed audio links.<br />
<br />
'''Filter video (.flv |.mp4 |.f4v | .mov)'''<br />
<br />
Enables/disables filtering for video audio links.<br />
<br />
'''Closed captions on by default'''<br />
<br />
Determines whether or not closed captioning plugins are loaded and displayed by default<br />
<br />
<br />
==Additional Documentation==<br />
[[Filters/rtmp]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=admin/setting/filtersettingrtmp&diff=111189admin/setting/filtersettingrtmp2014-03-19T14:19:49Z<p>Woolardfa: </p>
<hr />
<div><br />
'''Filter audio (.mp3)'''<br />
Enables/disables filtering for streamed audio links.<br />
==='''Filter video (.flv |.mp4 |.f4v | .mov)'''===<br />
Enables/disables filtering for video audio links.<br />
==='''Closed captions on by default'''===<br />
Determines whether or not closed captioning plugins are loaded and displayed by default<br />
<br />
<br />
==Additional Documentation==<br />
[[Filters/rtmp]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=admin/setting/filtersettingrtmp&diff=111188admin/setting/filtersettingrtmp2014-03-19T14:13:18Z<p>Woolardfa: Admin settings for filter_rtmp</p>
<hr />
<div>=Admin settings Streaming media filter (RTMP)=<br />
<br />
* Filter audio (.mp3) - Enables/disables filtering for streamed audio links.<br />
* Filter video (.flv |.mp4 |.f4v | .mov) - Enables/disables filtering for video audio links.<br />
* Closed captions on by default - Determines whether or not closed captioning plugins are loaded and displayed by default<br />
<br />
Additional Documentation: [[Filters/rtmp]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Filters/rtmp&diff=111181Filters/rtmp2014-03-19T13:48:29Z<p>Woolardfa: </p>
<hr />
<div>The '''RTMP streaming media filter''' is used to replace links containing URLs beginning with rtmp:// with a Flowplayer media player using their [http://flash.flowplayer.org/plugins/streaming/rtmp.html rtmp plugin]. It is contributed by [http://moodle.org/user/view.php?id=286444 Lacey Vickery] and [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Page output is examined for anchor href values beginning with rtmp:// and ending with a supported extension (currently .mp3, .mp4, .flv,, .f4v, and .mov). Qualifying links are replaced with a span tag containing 'data-' prefixed attributes that are subsequently used by the plugin's JavaScript module to apply a Flowplayer player to the span. The Adobe Flash Player browser plugin is required.<br />
<br />
The plugin was developed to work with Adobe's Flash Media Server, but according to Flowplayer, their [http://flash.flowplayer.org/plugins/streaming/rtmp.html RTMP plugin] should work with Wowza, and Red5 as well. The plugin has been tested successfully with Amazon's Cloudfront streaming service.<br />
<br />
=Installation=<br />
* Select the correct version of the filter_rtmp.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the '''filter/''' folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
* Enable and configure the plugin (Site administration->Plugins->Filters->Manage filters).<br />
<br />
=How to use=<br />
In places where you can enter HTML (e.g. wysiwyg editor for topic summary, page resource, etc.), create a link and supply a URL that references the media stream you want to play. The URL would look something like: ''rtmp://fms.example.org/vod/classes/lecture01.flv''<br />
<br />
The file extensions filtered are: '''.flv, .mp4, .f4v, .mov, and .mp3'''<br />
<br />
==Cloudfront Streams==<br />
Amazon's Cloudfront streaming requires the Flowplayer config values for netConnectionUrl, and the clip's URL to be slightly different. For streams originating at Cloudfront append the following query string paramter to the URL so the filter will adjust accordingly: '''?provider=acf'''<br />
<br />
=Playlists=<br />
Support for playlists has been added (v1.3). Refer to the [[Playlist plugin]] docs.<br />
<br />
=Closed Captions=<br />
Support for closed captioning has been added (v1.4). The filter can optionally load Flowplayer's [http://flash.flowplayer.org/plugins/flash/captions.html Captions] and [http://flash.flowplayer.org/plugins/flash/content.html Content] Flash plugins (.swf) to display closed captioning in the media player window. Even though Flowplayer's Caption plugin can load an external file containing the caption information, the filter does not yet provide for this method. The caption information must be embedded into the media file, such as an MP4 subtitles track, or FLV cuepoints.<br />
<br />
The filter has an additional site config to determine whether or not to load the Caption plugin by default. To override that default append the following query strting parameter to the URL: ''''?captions=1'''', or ''''captions=0'''', to load or not load the Captions plugin, respectively. These query string parameters are detected in playlists, so you can be selective about which clips in a playlist display closed captions.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=filter_rtmp here].<br />
<br />
=Source code=<br />
The source code repository is located at github.com in the [http://github.com/appalachianstate/moodle-filter_rtmp appalachianstate/moodle-filter_rtmp] repository.<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=SHEBanG_plugin&diff=106683SHEBanG plugin2013-09-19T21:24:40Z<p>Woolardfa: /* Important: Secure the target URL */</p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import messages from a SunGard HE Banner/LMB (Luminis Message Broker) installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for both Moodle 1.9 and 2.3.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installation of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
'''THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.'''<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin and shared with the Luminis admins.<br />
<br />
===Using Oracle===<br />
If Oracle is being used, the NLS_DATE_FORMAT session setting has to be adjusted from the default. SHEBanG expects it to be set to 'YYYY-MM-DD HH24:MI:SS', but if that is not practical for your installation (conflicts with other plugins, etc.) then the format used by SHEBanG can be changed in the lib.php (DATEFMT_SQL_VALUE).<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [https://moodle.org/plugins/view.php?plugin=enrol_shebang here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Filters/rtmp&diff=106603Filters/rtmp2013-09-12T14:58:15Z<p>Woolardfa: </p>
<hr />
<div>The '''RTMP streaming media filter''' is used to replace links containing URLs beginning with rtmp:// with a Flowplayer media player using their [http://flash.flowplayer.org/plugins/streaming/rtmp.html rtmp plugin]. It is contributed by [http://moodle.org/user/view.php?id=286444 Lacey Vickery] and [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Page output is examined for anchor href values beginning with rtmp:// and ending with a supported extension (currently .mp3, .mp4, .flv, and .f4v). Qualifying links are replaced with a div tag containing 'data-' prefixed attributes that are subsequently used by the plugin's JavaScript module to apply a Flowplayer player to the div. The Adobe Flash Player browser plugin is required.<br />
<br />
The plugin was developed to work with Adobe's Flash Media Server, but according to Flowplayer, their [http://flash.flowplayer.org/plugins/streaming/rtmp.html RTMP plugin] should work with Wowza, and Red5 as well. The plugin has been tested successfully with Amazon's Cloudfront streaming service.<br />
<br />
=Installation=<br />
* Select the correct version of the filter_rtmp.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the '''filter/''' folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
* Enable and configure the plugin (Site administration->Plugins->Filters->Manage filters).<br />
<br />
=How to use=<br />
In places where you can enter HTML (e.g. wysiwyg editor for topic summary, page resource, etc.), create a link and supply a URL that references the media stream you want to play. The URL would look something like: ''rtmp://fms.example.org/vod/classes/lecture01.flv''<br />
<br />
The file extensions filtered are: '''.flv, .mp4, .f4v, and .mp3'''<br />
<br />
==Cloudfront Streams==<br />
Amazon's Cloudfront streaming requires the Flowplayer config values for netConnectionUrl, and the clip's URL to be slightly different. For streams originating at Cloudfront append the following query string paramter to the URL so the filter will adjust accordingly: '''?provider=acf'''<br />
<br />
=Playlists=<br />
Support for playlists has been added. Refer to the [[Playlist plugin]] docs.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=filter_rtmp here].<br />
<br />
=Source code=<br />
The source code repository is located at github.com in the [http://github.com/appalachianstate/moodle-filter_rtmp appalachianstate/moodle-filter_rtmp] repository.<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Playlist_plugin&diff=106602Playlist plugin2013-09-12T14:47:58Z<p>Woolardfa: </p>
<hr />
<div>The '''Playlist resource plugin''' is used to save a named set of rtmp URLs which can then be referenced by [http://moodle.org/plugins/view.php?plugin=filter_rtmp filter_rtmp] plugin. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
To reference the playlist use the following form in a URL: rtmp://playlist=NAME, where 'NAME' would be the appropriate playlist name. The filter_rtmp will then build a playlist appearing with the Flowplayer player. Video playlists will appear beside the player, and audio playlists will appear below the player. Titles for each clip can be entered in the list by appending them to the URL separated by a comma (,). If no title is supplied, it will be taken from the last segment of the URL.<br />
<br />
URLs are currently validated to allow only those beginning with '''rtmp://'''. To prevent circular references, URLs with a playlist reference are not allowed.<br />
<br />
Playlist resources (not the rendered Flowplayer playlist) are meant to be visible only to users with the editing teacher, or manager roles.<br />
<br />
=Installation=<br />
* Select the correct version of the mod_playlist.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the mod/ folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
<br />
=How to use=<br />
Create a playlist resource with the rtmp URLs.<br />
<br />
[[File:playlist2.png]]<br />
<br />
Create a link somewhere that allows HTML (wysiwyg), e.g. a label, section/topic summary, page. In that link, reference the playlist.<br />
<br />
[[File:playlist3.png]]<br />
<br />
The Flowplayer player and rendered playlist.<br />
<br />
[[File:playlist.png]]<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=mod_playlist here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Playlist_plugin&diff=106601Playlist plugin2013-09-12T14:47:02Z<p>Woolardfa: </p>
<hr />
<div>The '''Playlist resource plugin''' is used to save a named set of rtmp URLs which can then be referenced by [http://moodle.org/plugins/view.php?plugin=filter_rtmp filter_rtmp] plugin. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
To reference the playlist use the following form in a URL: rtmp://playlist=NAME, where 'NAME' would be the appropriate playlist name. The filter_rtmp will then build a playlist appearing with the Flowplayer player. Video playlists will appear beside the player, and audio playlists will appear below the player. Titles for each clip can be entered in the list by appending them to the URL separated by a comma (,). If no title is supplied, it will be taken from the last segment of the URL.<br />
<br />
URLs are currently validated to allow only those beginning with '''rtmp://'''. To prevent circular references, URLs with a playlist reference are not allowed.<br />
<br />
Playlist resources (not the rendered Flowplayer playlist) are meant to be visible only to users with the editing teacher, or manager roles.<br />
<br />
=Installation=<br />
* Select the correct version of the mod_playlist.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the mod/ folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
<br />
=Rendered Playlist=<br />
Create a playlist resource with the rtmp URLs.<br />
<br />
[[File:playlist2.png]]<br />
<br />
Create a link somewhere that allows HTML (wysiwyg), e.g. a label, section/topic summary, page. In that link, reference the playlist.<br />
<br />
[[File:playlist3.png]]<br />
<br />
The Flowplayer player and rendered playlist.<br />
<br />
[[File:playlist.png]]<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=mod_playlist here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=File:playlist3.png&diff=106600File:playlist3.png2013-09-12T14:41:32Z<p>Woolardfa: In a label, adding an rtmp link that references a playlist</p>
<hr />
<div>In a label, adding an rtmp link that references a playlist</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Playlist_plugin&diff=106599Playlist plugin2013-09-12T14:37:42Z<p>Woolardfa: </p>
<hr />
<div>The '''Playlist resource plugin''' is used to save a named set of rtmp URLs which can then be referenced by [http://moodle.org/plugins/view.php?plugin=filter_rtmp filter_rtmp] plugin. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
To reference the playlist use the following form in a URL: rtmp://playlist=NAME, where 'NAME' would be the appropriate playlist name. The filter_rtmp will then build a playlist appearing with the Flowplayer player. Video playlists will appear beside the player, and audio playlists will appear below the player. Titles for each clip can be entered in the list by appending them to the URL separated by a comma (,). If no title is supplied, it will be taken from the last segment of the URL.<br />
<br />
URLs are currently validated to allow only those beginning with '''rtmp://'''. To prevent circular references, URLs with a playlist reference are not allowed.<br />
<br />
Playlist resources (not the rendered Flowplayer playlist) are meant to be visible only to users with the editing teacher, or manager roles.<br />
<br />
=Installation=<br />
* Select the correct version of the mod_playlist.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the mod/ folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
<br />
=Rendered Playlist=<br />
[[File:playlist2.png]][[File:playlist.png]]<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=mod_playlist here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=File:playlist2.png&diff=106598File:playlist2.png2013-09-12T14:32:07Z<p>Woolardfa: Creating a playlist</p>
<hr />
<div>Creating a playlist</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Playlist_plugin&diff=106597Playlist plugin2013-09-12T14:01:09Z<p>Woolardfa: </p>
<hr />
<div>The '''Playlist resource plugin''' is used to save a named set of rtmp URLs which can then be referenced by [http://moodle.org/plugins/view.php?plugin=filter_rtmp filter_rtmp] plugin. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
To reference the playlist use the following form in a URL: rtmp://playlist=NAME, where 'NAME' would be the appropriate playlist name. The filter_rtmp will then build a playlist appearing with the Flowplayer player. Video playlists will appear beside the player, and audio playlists will appear below the player. Titles for each clip can be entered in the list by appending them to the URL separated by a comma (,). If no title is supplied, it will be taken from the last segment of the URL.<br />
<br />
URLs are currently validated to allow only those beginning with '''rtmp://'''. To prevent circular references, URLs with a playlist reference are not allowed.<br />
<br />
Playlist resources (not the rendered Flowplayer playlist) are meant to be visible only to users with the editing teacher, or manager roles.<br />
<br />
=Installation=<br />
* Select the correct version of the mod_playlist.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the mod/ folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
<br />
=Rendered Playlist=<br />
[[File:playlist.png]]<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=mod_playlist here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=File:playlist.png&diff=106596File:playlist.png2013-09-12T13:59:28Z<p>Woolardfa: Example of filter_rtmp rendered playlist</p>
<hr />
<div>Example of filter_rtmp rendered playlist</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Playlist_plugin&diff=106595Playlist plugin2013-09-12T13:56:23Z<p>Woolardfa: Created page with "The '''Playlist resource plugin''' is used to save a named set of rtmp URLs which can then be referenced by [http://moodle.org/plugins/view.php?plugin=filter_rtmp filter_rtmp]..."</p>
<hr />
<div>The '''Playlist resource plugin''' is used to save a named set of rtmp URLs which can then be referenced by [http://moodle.org/plugins/view.php?plugin=filter_rtmp filter_rtmp] plugin. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
To reference the playlist use the following form in a URL: rtmp://playlist=NAME, where 'NAME' would be the appropriate playlist name. The filter_rtmp will then build a playlist appearing with the Flowplayer player. Video playlists will appear beside the player, and audio playlists will appear below the player. Titles for each clip can be entered in the list by appending them to the URL separated by a comma (,). If no title is supplied, it will be taken from the last segment of the URL.<br />
<br />
URLs are currently validated to allow only those beginning with '''rtmp://'''. To prevent circular references, URLs with a playlist reference are not allowed.<br />
<br />
Playlist resources (not the rendered Flowplayer playlist) are meant to be visible only to users with the editing teacher, or manager roles.<br />
<br />
=Installation=<br />
* Select the correct version of the mod_playlist.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the mod/ folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/plugins/view.php?plugin=mod_playlist here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=SHEBanG_plugin&diff=106594SHEBanG plugin2013-09-12T13:22:11Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import messages from a SunGard HE Banner/LMB (Luminis Message Broker) installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for both Moodle 1.9 and 2.3.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installation of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin and shared with the Luminis admins.<br />
===Using Oracle===<br />
If Oracle is being used, the NLS_DATE_FORMAT session setting has to be adjusted from the default. SHEBanG expects it to be set to 'YYYY-MM-DD HH24:MI:SS', but if that is not practical for your installation (conflicts with other plugins, etc.) then the format used by SHEBanG can be changed in the lib.php (DATEFMT_SQL_VALUE).<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [https://moodle.org/plugins/view.php?plugin=enrol_shebang here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Filters/rtmp&diff=103442Filters/rtmp2013-03-01T19:28:32Z<p>Woolardfa: Add How to use section</p>
<hr />
<div>The '''RTMP streaming media filter''' is used to replace links containing URLs beginning with rtmp:// with a Flowplayer media player using their [http://flash.flowplayer.org/plugins/streaming/rtmp.html rtmp plugin]. It is contributed by [https://moodle.org/user/view.php?id=286444 Lacey Vickery] and [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for Moodle 2.3 and 2.4.<br />
<br />
Page output is examined for anchor href values beginning with rtmp:// and ending with a supported extension (currently .mp3, .mp4, and .flv). Qualifying links are replaced with a span tag containing 'data-' prefixed attributes that are subsequently used by the plugin's JavaScript module to apply a Flowplayer player to the span. The Adobe Flash Player browser plugin is required.<br />
<br />
The plugin was developed to work with Adobe's Flash Media Server, but according to Flowplayer, their [http://flash.flowplayer.org/plugins/streaming/rtmp.html rtmp plugin] should work with Wowza, and Red5 as well. The plugin has been tested successfully with Amazon's Cloudfront streaming service.<br />
<br />
=Installation=<br />
* Select the correct version of the filter_rtmp.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the '''filter/''' folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
* Enable and configure the plugin (Site administration->Plugins->Filters->Manage filters).<br />
<br />
=How to use=<br />
In places where you can enter HTML (e.g. wysiwyg editor for topic summary, page resource, etc.), create a link and supply a URL that references the media stream you want to play. The URL would look something like: ''rtmp://fms.example.org/vod/classes/lecture01.flv''<br />
<br />
The file extensions filtered are: '''.flv, .mp4, and .mp3'''<br />
<br />
==Cloudfront Streams==<br />
Amazon's Cloudfront streaming requires the Flowplayer config values for netConnectionUrl, and the clip's URL to be slightly different. For streams originating at Cloudfront append the following query string paramter to the URL so the filter will adjust accordingly: '''?provider=acf'''<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [https://moodle.org/plugins/view.php?plugin=filter_rtmp here].<br />
<br />
=Source code=<br />
The source code repository is located at github.com in the [https://github.com/appalachianstate/moodle-filter_rtmp appalachianstate/moodle-filter_rtmp] repository.<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Filters/rtmp&diff=103435Filters/rtmp2013-02-28T13:59:49Z<p>Woolardfa: RTMP streaming media filter plugin</p>
<hr />
<div>The '''RTMP streaming media filter''' is used to replace links containing URLs beginning with rtmp:// with a Flowplayer media player using their [http://flash.flowplayer.org/plugins/streaming/rtmp.html rtmp plugin]. It is contributed by [https://moodle.org/user/view.php?id=286444 Lacey Vickery] and [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for Moodle 2.3 and 2.4.<br />
<br />
Page output is examined for anchor href values beginning with rtmp:// and ending with a supported extension (currently .mp3, .mp4, and .flv). Qualifying links are replaced with a span tag containing 'data-' prefixed attributes that are subsequently used by the plugin's JavaScript module to apply a Flowplayer player to the span. The Adobe Flash Player browser plugin is required.<br />
<br />
The plugin was developed to work with Adobe's Flash Media Server, but according to Flowplayer, their [http://flash.flowplayer.org/plugins/streaming/rtmp.html rtmp plugin] should work with Wowza, and Red5 as well. The plugin has been tested successfully with Amazon's Cloudfront streaming service.<br />
<br />
=Installation=<br />
* Select the correct version of the filter_rtmp.zip plugin for your Moodle installation.<br />
* Unpack the .zip file into the '''filter/''' folder of your Moodle site.<br />
* Access the notifications page (Site administration->Notifications) to initiate installation.<br />
* Enable and configure the plugin (Site administration->Plugins->Filters->Manage filters).<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [https://moodle.org/plugins/view.php?plugin=filter_rtmp here].<br />
<br />
=Source code=<br />
The source code repository is located at github.com in the [https://github.com/appalachianstate/moodle-filter_rtmp appalachianstate/moodle-filter_rtmp] repository.<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Filters/rtmp&diff=103424Filters/rtmp2013-02-28T03:12:44Z<p>Woolardfa: Created page with "The RTMP streaming media filter is used to replace links containing URLs beginning with rtmp:// with a Flowplayer player using their rtmp plugin."</p>
<hr />
<div>The RTMP streaming media filter is used to replace links containing URLs beginning with rtmp:// with a Flowplayer player using their rtmp plugin.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=SHEBanG_plugin&diff=99308SHEBanG plugin2012-07-18T19:34:35Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import messages from a SunGard HE Banner/LMB (Luminis Message Broker) installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for both Moodle 1.9 and 2.3.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installation of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin and shared with the Luminis admins.<br />
===Using Oracle===<br />
If Oracle is being used, the NLS_DATE_FORMAT session setting has to be adjusted from the default. SHEBanG expects it to be set to 'YYYY-MM-DD HH24:MI:SS', but if that is not practical for your installation (conflicts with other plugins, etc.) then the format used by SHEBanG can be changed in the lib.php (DATEFMT_SQL_VALUE).<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=SHEBanG_plugin&diff=85271SHEBanG plugin2011-06-17T15:50:17Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import messages from a SunGard HE Banner/LMB (Luminis Message Broker) installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for both Moodle 1.9 and 2.0.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installation of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin and shared with the Luminis admins.<br />
===Using Oracle===<br />
If Oracle is being used, the NLS_DATE_FORMAT session setting has to be adjusted from the default. SHEBanG expects it to be set to 'YYYY-MM-DD HH24:MI:SS', but if that is not practical for your installation (conflicts with other plugins, etc.) then the format used by SHEBanG can be changed in the lib.php (DATEFMT_SQL_VALUE).<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=82916Development:SHEBanG plugin2011-04-21T15:42:45Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin (beta)''' is designed to import messages from a SunGard HE Banner/LMB (Luminis Message Broker) installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for both Moodle 1.9 and 2.0. It is currently designated '''beta''' because it has only been deployed in a QA/test environment, and not yet put into production by its author.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
===Using Oracle===<br />
If Oracle is being used, the NLS_DATE_FORMAT session setting has to be adjusted from the default. SHEBanG expects it to be set to 'YYYY-MM-DD HH24:MI:SS', but if that is not practical for your installation (conflicts with other plugins, etc.) then the format used by SHEBanG can be changed in the lib.php (DATEFMT_SQL_VALUE).<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=82148Development:SHEBanG plugin2011-03-21T18:10:10Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin (beta)''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for both Moodle 1.9 and 2.0. It is currently designated '''beta''' because it has only been deployed in a QA/test environment, and not yet put into production by its author.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
===Using Oracle===<br />
If Oracle is being used, the NLS_DATE_FORMAT session setting has to be adjusted from the default. SHEBanG expects it to be set to 'YYYY-MM-DD HH24:MI:SS', but if that is not practical for your installation (conflicts with other plugins, etc.) then the format used by SHEBanG can be changed in the lib.php (DATEFMT_SQL_VALUE).<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=82117Development:SHEBanG plugin2011-03-21T01:40:53Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin (beta)''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard]. Versions are available for both Moodle 1.9 and 2.0. It is currently designated '''beta''' because it has only been deployed in a QA/test environment, and not yet put into production by its author.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=82033Development:SHEBanG plugin2011-03-18T01:23:06Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin (beta)''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard], and was developed and tested in Moodle version 1.9.9; it is currently designated '''beta''' because it has only been deployed in a QA/test environment, and not yet put into production by its author.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>https://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=76534Development:SHEBanG plugin2010-10-06T16:41:10Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin (beta)''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard], and was developed and tested in Moodle version 1.9.9; it is currently designated '''beta''' because it has only been deployed in a QA/test environment, and not yet put into production by its author.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>http://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=76532Development:SHEBanG plugin2010-10-06T16:20:38Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard], and was developed and tested in Moodle version 1.9.9; it is currently designated '''beta''' because it has only been deployed in a QA/test environment, and not yet put into production by its author.<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>http://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=76531Development:SHEBanG plugin2010-10-06T16:11:05Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>http://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
<br />
=Considerations For Blocking Issues=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=76530Development:SHEBanG plugin2010-10-06T16:10:34Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
=Why write a new one? Why reinvent?=<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
==Some other differences==<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
=Installation=<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the target URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>http://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===Important: Secure the target URL===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT THIS SHOULD NOT BE YOUR FIRST CHOICE. AGAIN, IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET (SSL) CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
<br />
=CONSIDERATIONS FOR BLOCKING ISSUES=<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
=How Entities are Associated and Referenced=<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
=Where to Find=<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=76529Development:SHEBanG plugin2010-10-06T16:01:48Z<p>Woolardfa: </p>
<hr />
<div>The '''SHEBanG enrolment plugin''' is designed to import Luminis Message Broker (LMB) messages containing data sent from a SunGard HE Banner&reg; installation. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Messages are POSTed by LMB to a specified URL; that URL should end up resolving to enrol/shebang/secure/post.php either by means of direct address, symbolic link, or Apache server configuration (e.g. alias). An alternate method of import is the file upload feature.<br />
<br />
There already is an enrollment plugin, LMB, developed by [http://moodle.org/user/view.php?id=139623 Eric Merrill] that processes Banner data, and has many more configuration options and features. We have been using this plugin for several years at Appalachian State with only a few basic alterations.<br />
<br />
==Why write a new one? Why reinvent?==<br />
There were a few reasons.<br />
<br />
In our particular installtion of Banner/LMB, we kept getting several essentially identical messages which resulted in duplicate rows in one of the staging tables. Normally not a big problem, but eventually the staging table becomes bloated with duplicates, and since this table is involved in JOINs where a singleton query result is expected. We also wanted to log each of the XML messages received, but not in the database; logging the messages in a text file is more practical for us.<br />
<br />
Messages sent by the LMB are logged to the file-system in the Moodle data directory rather than the database; this message log file is locked exclusively while the message is being processed in order to serialize message processing.<br />
<br />
In the case where additional data from the XML message was needed, a regular expression had to be added--most often this is simple enough given an existing pattern from which to start, but in some instances where the message format changes ever so slightly (e.g. recstatus), it makes more sense to use DOMXPath queries to extract message data.<br />
<br />
XMLParser is used to break up the input, whether from file or posted XML, into the principle elements we want (<group>, <person>, and <membership>), and from that point use the DOMDocument and DOMXPath to query for the needed values.<br />
<br />
=Some other differences=<br />
*Messages imported from a file are not logged since there's already a source file;<br />
*A cross-list course parent is created only when the first <membership> message for that cross-list arrives, and then it will be created by making a copy of the child course.<br />
*The Moodle user's idnumber column is populated with the SCTID/Banner userid, rather than the Luminis sourcedid/id.<br />
*The only cron activity is the monitor for last message arrival time. Some Moodle sites may have a very frequent cron activity (5-10 min) so it didn't seem practical to put directory/file check tasks in a common script--rather use a dedicated cron task, if needed at all, for the Banner extract/batch-file imports.<br />
<br />
==Installation==<br />
SHEBanG requires that PHP modules XMLParser, DOMDocument, and DOMXPath be loaded.<br />
* Select the correct version of the "shebang.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the enrol folder of your Moodle site<br />
* Access the notifications page (Admin block->Notifications) to initiate database setup.<br />
* Enable and configure the plugin (Courses->Enrolments->SHEBanG[Edit]).<br />
* Configure your Banner/LMB to POST messages to the URL corresponding to the enrol/shebang/secure/post.php file, for example: <nowiki>http://moodle.someuniversity.edu/enrol/shebang/secure/post.php</nowiki><br />
===I M P O R T A N T===<br />
THIS URL NEEDS TO BE SECURED IN SOME FASHION TO PREVENT UNAUTHORIZED USERS FROM INJECTING ERRANT DATA INTO YOUR DATABASE. THE METHODS FOR SECURING THIS URL INCLUDE, BUT ARE NOT LIMITED TO, APACHE HTTP AUTH CONFIGURED--IDEALLY WITH SSL--AT THE SERVER/VHOST/DIRECTORY LEVEL OR WITH AN .htaccess FILE. ANOTHER OPTION, IS TO USE THE AUTHENTICATION FEATURE IN THE MODULE, BUT AGAIN IT IS STRONGLY RECOMMENDED TO USE A SECURE SOCKET CONNECTION IN ADDITION TO HTTP BASIC OR DIGEST AUTHENTICATION SINCE EITHER THE USERID/PWD INFORMATION WILL BE EXPOSED WHEN SENT IN CLEAR-TEXT (BASIC) OR THE HASH (DIGEST) WILL BE EXPOSED.<br />
<br />
There is no Moodle authentication protection in the post.php since it is accessed by an external, non-interactive service where a userid/password will be configured by the Moodle server admin<br />
and shared with the Luminis admins.<br />
<br />
==CONSIDERATIONS FOR BLOCKING ISSUES==<br />
Because SHEBanG serializes message processing using a file lock, it is possible, in some cases likely, that a blocking bottleneck will take place when a large number of messages are sent by Banner/LMB at or near the same time. To mitigate the risk of the all the Apache worker processes being occupied and blocked, and thus freezing out the application end-users, consider setting up another Apache daemon to handle LMB messages exclusively on an alternate port such as 8080. In this way you can tailor the configured number of initial, max-min spare worker processes, etc., and if these processes should become consumed, the end-users will not be impacted.<br />
<br />
==HOW ENTITIES ARE ASSOICATED AND REFERENCED==<br />
*Courses<br />
A staging record in the [mdl_enrol_shebang_section] table is inserted or updated, using the <sourcedid><id> value (the CRN) as the alternate key. This same value is placed in the [mdl_course](idnumber) column so that table can be queried directory. The course's (idnumber) value can not be changed after that or the association will be lost.<br />
<br />
*Users<br />
A staging record in the [mdl_enrol_shebang_person] table is inserted or updated, using the <sourcedid><id> value (the Luminis Id for that Banner identity, distinct from the Banner identity value). Susbsequent <membership> messages for this person will use this <sourcedid><id> so we need to use this as an alternate identifying key value. A <person> message also contains the <userid useridtype="SCTID"> value, the Banner identity, and it's this value that is placed in the [mdl_user] (idnumber) column.<br />
<br />
So, upon arrival of a <person> message, and after the staging record is handled, the [mdl_user] table is queried on the (idnumber) column for the SCTID value--if no record is found, then an attempt is made to insert one, otherwise the found record is updated. Because other columns in the [mdl_user] table are unique (enforced either by the application or the database), a collision on email or username by prevent the insert. In such cases, manual inspection of the existing user account should be done to determine if it can be deleted (no access, no enrolments, etc.) or if it should be associated with the corresponding [mdl_enrol_shebang_person] row by placing the appropriate Banner identity value in the user's (idnumber) column.<br />
<br />
Until any such collision is resolved, course enrollments for that person/user will fail since no association exists between the person entity and the user entity.<br />
<br />
==Where to Find==<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4264 here].<br />
<br />
[[Category:Contributed code]]</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:SHEBanG_plugin&diff=76499Development:SHEBanG plugin2010-10-06T03:38:51Z<p>Woolardfa: SHEBanG enrolment plugin</p>
<hr />
<div>SHEBanG enrolment plugin</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74335Development:Userenrols plugin2010-07-29T18:19:35Z<p>Woolardfa: /* Installation */</p>
<hr />
<div>The '''userenrols course import plugin''' allows you to do an ad hoc import of user enrollments for a course from an uploaded text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are made using a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why Use This Plugin?==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts on the system (and no update of those user accounts is needed or desired).<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the course/import folder of your Moodle site<br />
* Move the Lang/Help files<br />
** Copy the userenrols/lang/en_utf8/import_userenrols.php file into the /lang/en_utf8 (or your preferred lang) directory of the Moodle site<br />
** Copy the userenrols/lang/en_utf8/help/userenrols directory into the /lang/en_utf8/help directory of the Moodle site AND THEN RENAME IT TO import_userenrols<br />
<br />
==Where to Find==<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4044 here].<br />
<br />
<br />
<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74334Development:Userenrols plugin2010-07-29T18:15:29Z<p>Woolardfa: </p>
<hr />
<div>The '''userenrols course import plugin''' allows you to do an ad hoc import of user enrollments for a course from an uploaded text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are made using a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why Use This Plugin?==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts on the system (and no update of those user accounts is needed or desired).<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Unpack the .zip file into the course/import folder of your Moodle site<br />
* Copy the userenrols/lang/en_utf8/import_userenrols.php file into the /lang/en_utf8 (or your preferred lang) directory of the Moodle site<br />
* Copy the userenrols/lang/en_utf8/help/userenrols directory into the /lang/en_utf8/help directory of the Moodle site AND THEN RENAME IT TO import_userenrols<br />
<br />
==Where to Find==<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4044 here].<br />
<br />
<br />
<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74333Development:Userenrols plugin2010-07-29T18:10:13Z<p>Woolardfa: /* Where to Find */</p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why Use This Plugin?==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts on the system (and no update of those user accounts is needed or desired).<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Unpack the zip file into the course/import folder of your Moodle site<br />
* Copy the userenrols/lang/en_utf8/import_userenrols.php file into the /lang/en_utf8 (or your preferred lang) directory of the Moodle site<br />
* Copy the userenrols/lang/en_utf8/help/userenrols directory into the /lang/en_utf8/help directory of the Moodle site AND THEN RENAME IT TO import_userenrols<br />
<br />
==Where to Find==<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4044 here].<br />
<br />
<br />
<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74332Development:Userenrols plugin2010-07-29T18:08:53Z<p>Woolardfa: /* Why This Plugin */</p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why Use This Plugin?==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts on the system (and no update of those user accounts is needed or desired).<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Unpack the zip file into the course/import folder of your Moodle site<br />
* Copy the userenrols/lang/en_utf8/import_userenrols.php file into the /lang/en_utf8 (or your preferred lang) directory of the Moodle site<br />
* Copy the userenrols/lang/en_utf8/help/userenrols directory into the /lang/en_utf8/help directory of the Moodle site AND THEN RENAME IT TO import_userenrols<br />
<br />
==Where to Find==<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4044 here].<br />
<br />
<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74283Development:Userenrols plugin2010-07-29T04:37:14Z<p>Woolardfa: </p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why This Plugin==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts.<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Unpack the zip file into the course/import folder of your Moodle site<br />
* Copy the userenrols/lang/en_utf8/import_userenrols.php file into the /lang/en_utf8 (or your preferred lang) directory of the Moodle site<br />
* Copy the userenrols/lang/en_utf8/help/userenrols directory into the /lang/en_utf8/help directory of the Moodle site AND THEN RENAME IT TO import_userenrols<br />
<br />
==Where to Find==<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4044 here].<br />
<br />
<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74282Development:Userenrols plugin2010-07-29T04:33:17Z<p>Woolardfa: </p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why This Plugin==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts.<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Unpack the zip file into the course/import folder of your Moodle site<br />
* Copy the userenrols/lang/en_utf8/import_userenrols.php file into the /lang/en_utf8 (or your preferred lang) directory of the Moodle site<br />
* Copy the userenrols/lang/en_utf8/help/userenrols directory into the /lang/en_utf8/help directory of the Moodle site AND THEN RENAME IT TO import_userenrols<br />
<br />
==Where to Find==<br />
The plugin can be found in the Modules and plugins database [http://moodle.org/mod/data/view.php?d=13&rid=4044 here].<br />
<br />
== ==<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74281Development:Userenrols plugin2010-07-29T04:26:03Z<p>Woolardfa: /* Installation */</p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why This Plugin==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts.<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Unpack the zip file into the course/import folder of your Moodle site<br />
* Copy the userenrols/lang/en_utf8/import_userenrols.php file into the /lang/en_utf8 (or your preferred lang) directory of the Moodle site<br />
* Copy the userenrols/lang/en_utf8/help/userenrols directory into the /lang/en_utf8/help directory of the Moodle site AND THEN RENAME IT TO import_userenrols<br />
<br />
== ==<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74280Development:Userenrols plugin2010-07-29T03:53:41Z<p>Woolardfa: </p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why This Plugin==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts.<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Uppack the zip file into the course/import folder of your Moodle site<br />
* Read the INSTALL.txt file for details on either installing a patch or copying the plugin's lang and help files<br />
<br />
== ==<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74279Development:Userenrols plugin2010-07-29T03:52:42Z<p>Woolardfa: </p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
==Why This Plugin==<br />
Site administrators can accomplish the same task using the "Upload Users" interface from the Users->Accounts menu. However, this plugin is meant to be used by a course instructor, or anyone who has the [moodle/role:assign] capability for a given course, to make any number of ad hoc manual enrollments of users who already have accounts.<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Uppack the zip file into the course/import folder of your Moodle site<br />
* Read the INSTALL.txt file for details on either installing a patch or copying the plugin's lang and help files</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74266Development:Userenrols plugin2010-07-28T23:45:49Z<p>Woolardfa: </p>
<hr />
<div>The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Uppack the zip file into the course/import folder of your Moodle site<br />
* Read the INSTALL.txt file for details on either installing a patch or moving the plugin's lang files</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74265Development:Userenrols plugin2010-07-28T23:44:32Z<p>Woolardfa: </p>
<hr />
<div>{{userenrols}}<br />
<br />
The '''userenrols course import plugin''' allows you to import user enrollments for a course from an uploaded delimited text file. It is contributed by [http://moodle.org/user/view.php?id=268334 Fred Woolard].<br />
<br />
Enrollments are associated with a selectable course role, and the plugin can optionally create course groups and assign the new enrollees to those groups.<br />
<br />
Each of the users listed in the input file must have an existing Moodle user account; new Moodle user accounts will not be created.<br />
<br />
This plugin is a refactor of the [http://moodle.org/mod/data/view.php?d=13&rid=3595 mass_enroll] course admin mod done by [http://moodle.org/user/view.php?id=69061 Patrick Pollet] and [http://moodle.org/user/view.php?id=34826 Valery Fremaux], using the standard groups course import plugin as a template.<br />
<br />
==Installation==<br />
* Select the correct version of the "userenrols.zip" plugin for your Moodle installation<br />
* Uppack the zip file into the course/import folder of your Moodle site<br />
* Read the INSTALL.txt file for details on either installing a patch or moving the plugin's lang files</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74264Development:Userenrols plugin2010-07-28T22:37:21Z<p>Woolardfa: </p>
<hr />
<div>This course import plugin allows you to import user enrollments from an uploaded delimited text file. New user accounts will not be created, so each of the users listed in the input file must already have an account set up in the site. The course role into which new enrollments are made is selectable. Optionally, you also can assign imported users to course groups as part of the same import process.<br />
<br />
This plugin is a refactor of the mass_enroll course admin mod done by Patrick Pollet and Valery Fremaux, using the existing groups import plugin (Jamie Pratt & Tim Hunt ?) as a template.</div>Woolardfahttps://docs.moodle.org/310/en/index.php?title=Development:Userenrols_plugin&diff=74260Development:Userenrols plugin2010-07-28T21:25:44Z<p>Woolardfa: New page: The Userenrols course import plugin is used to make a large number of ad hoc manual enrollments in a course using an uploaded text containing the list of enrollees. The course role into wh...</p>
<hr />
<div>The Userenrols course import plugin is used to make a large number of ad hoc manual enrollments in a course using an uploaded text containing the list of enrollees. The course role into which new enrollments are made is selectable, and new course participants can be assigned into groups as part of the same import process.</div>Woolardfa