UniversalTemplate/logo.png UniversalTemplate/UTS.png UNDER CONSTRUCTION

A. Introduction: Degree Works version 507sp1 as of 8/10/2022

Ellucian Degree Works™ is a comprehensive academic advising, transfer articulation, and degree audit solution that aligns students, advisors, and institutions to a common goal: helping students graduate on time.

  • A.1. Benefits of using Degree Works:

  • Creation of student audits on demand using worksheets and degree audits.
  • Clear visual indicators showing degree course requirements and progress.
  • Degree progress is accessible on-line for both students and staff.
  • Advising tool.
  • Planning and forecasting tool.
  • Exception tracker.


B. Design: Architectural, Functional, Authentification

  • B.1. Architecture



B.3. Functional Process Flow Example

  • First: Creation of "Scribe" (programming code). Scribe is a DW (Degree Works) language consisting of certain keywords and syntactical rules used to define institutional requirements into the computer. The institutional requirements are entered using a program called Scribe, resulting in a series of requirement blocks. These blocks are then read by the first of the two DW processing engines. The Parser engine validates the requirement blocks, assuring they are lexically and syntactically correct so that they may be properly interpreted by the Auditor engine.

  • Second: The Auditor engine reconciles student academic data from the student information system with the requirement blocks that have been built by users and then validated by the Parser engine. The Auditor engine actually evaluates the student course data against the appropriate requirement blocks, determining which academic requirements have been satisfied and which await completion. The audit results are stored in a database for reporting and review by the institutional staff.

  • Third: The Output engine interprets the audit results and produces printed and online audit reports. Online viewing of audit results is accomplished using DW on the web, which may be made available to the Registrar, faculty or students. It is through DW on the web that exceptions and substitutions are entered as well as advisor notes. Security to control "who accesses what" is enforced by DW on the web.

B.4. Functional Process Flow Example

  1. Programmer (Scriber) interprets OU course catalog into Degree Works code called Requirement Blocks.
  2. The Requirement Blocks are read by Parser Engine. (Scripts on Web/Classic server above: DAP16 batch & DAP13 online)

  3. Auditor Engine combines student data with Parser Engine output to produce "Audits". (Scripts on Web/Classic server above: DAP22 batch & DAP14 online)

  4. Nightly cron job on Web/Classic server (dwadmin userid/RAD30) runs batch job to pull students into Degree Works database from Banner database. (Other batch extracts also run... explained in Operational/Support Section) Commonly called the DW Bridge or BIF.

B.5. Functional Process Flow Example

  • First: Parser Engine

  • Institution's degree requirements are "put into" or scribed into blocks.
  • These blocks are checked to make sure they are syntactically correct through the use of a Parser Engine.
  • Once they are determined to be correct, the blocks can be saved and used by Degree Works.
  • DAP13 is the program that runs the parser engine.

    Second: Auditor Engine

  • Once the blocks have been successfully parsed and saved, they can be used to compare against the student's data to determine if the student meets the block's requirements.
  • This comparison is called the Auditor Engine.
  • The results from this comparison are stored in the database for reporting and for viewing by either institutional staff(advisors, registrar, etc.) or the student.
  • The Auditor Engine is a program called DAPaudit or DAP22.

    Third: Output Engine

  • Interprets the audit results.
  • Produces printed and online audit reports.
  • Online viewing of the audit results is accomplished using Degree Works on the Web.
  • DAP15 is the program that runs the output engine.


B.6. Authentification Flow for DW Dashboard URL IMG_Arch4_Dash.JPG

B.7. Authentification Flow for DW Scribe URL IMG_Arch5_Scribe.JPG

B.8. Authentification Flow for DW Admin URL IMG_Arch6_Admin.JPG

B.9. Authentification Flow for DW Transfer Equiv URL IMG_Arch7_Transfer.JPG

B.10. Authentification Flow for DW Transit PC Tool IMG_Arch8_Transit.JPG


C. Better DW Reporting with Argos

TBD - CPA engine, Argos pre-written blocks...


D. Operations / Support / How-to

D.1. Documentation Locations

D.2. Web URL'S

D.3. Hosts

  • TEST
    • Web/Classic Server - ea-dwclassic-t03.dev.oakland.edu

    • Springboot Server - ea-dwsb-t03.dev.oakland.edu

    • Oracle Database Server - ea-bantestdb-t01.dev.oakland.edu

    • Degree Works - ORALCE_SID = DWTEST

  • Banner - ORACLE_SID = TEST

  • PROD
  • Web/Classic Server - ea-dwclassic-p03.sys.oakland.edu

  • Springboot Server - ea-dwsb-p03.sys.oakland.edu

  • Oracle Database Server - ea-banproddb-p01.sys.oakland.edu

  • Degree Works - ORALCE_SID = DWPROD

  • Banner - ORACLE_SID = PROD

D.4. Start and Stop Degree Works

  • TEST
    • 1st - On the Java application server (dwjaptst.oakland.edu or bdwtomcatfe2.dev.oakland.edu)
    • 2nd - login, and type "sudo service tomcat restart"
    • 3rd - enter your NetID password when prompted
    • 4th - On the DW application server (dwapptst.oakland.edu or bdwdapwebfe2.dev.oakland.edu.) …
    • 5th - login, and type "sudo /etc/init.d/dwservice restart"
    • 6th - again, enter your NetID password when prompted
    • 7th - Sign into bdwtransfereqfe2.dev.oakland.edu
    • 8th - sudo systemctl start/stop transferequiv.service
    • Now the Degree works App and Web servers and related services have been restarted.
    • Note: For database restarts or issues see UTS DBA's...(footprint ticket as appropriate...)
      • PROD
    • 1st - On the Java application server (dwjap.oakland.edu or bdwtomcatfe1.sys.oakland.edu)
    • 2nd - login, and type "sudo service tomcat restart"
    • 3rd - enter your NetID password when prompted
    • 4th - On the DW application server (dwapp.oakland.edu or bdwdapwebfe1.sys.oakland.edu.) …
    • 5th - login, and type "sudo /etc/init.d/dwservice restart"
    • 6th - again, enter your NetID password when prompted
    • 7th - Sign into bdwtransfereqfe1.sys.oakland.edu
    • 8th - sudo systemctl start/stop transferequiv.service
    • Now the Degree works App and Web servers and related services have been restarted.
    • Note: For database restarts or issues see UTS DBA's...(footprint ticket as appropriate...)
  • Explanation of what is happening:


  • It is a good practice to restart the Degree Works dap and web daemon processes nightly via crontab, and whenever either the Degree Works database or the Banner database is shutdown. With both databases running, log on as dwadmin and run: daprestart webrestart

  • When it is necessary to reboot the Degree Works application server:

  • If possible, first log on as dwadmin and stop the Degree Works daemons with these commands: dapstop webstop
  • Reboot the Degree Works application server.
  • Ensure the databases (DW and Banner) and listeners are up on the database server(s).
  • Log on as dwadmin and start the Degree Works daemons with these commands: daprestart webrestart Ø Please see the Degree Works Technical Guide for more information on these and other commands. All Degree Works documentation can be downloaded from the Ellucian Customer Support Center


D.5. Extracts

  • Applicant(ban40) Student(ban40) Advisor(ban45) Staff(ban45) Course(ban41) Equiv(ban43) UCX(ban44) - Note!!! Only run once during setup, running this again will wipe out configuration tables...

D.6. Monitoring

  • TBD- SiteMonitor?

D.7. Tools

  • Transit PC Tool Debugging

D.8. Password Resets

D.9. OU DW advisor user add

1. The request will start with the DegreeWorks - User Request Form being filled out. https://forms.oakland.edu/

2. DW User Access Forms Request.png

3. Once approved by the submitter, a FootPrints Ticket will appear in our queue.

4. Footprints_Queue.png

5. Open the ticket and copy the URL shown at the bottom into a Chrome incognito browser.

6. DW_Chrome_incognito_browser.png

7. You should be prompted to enter id/pw to get into PerfectForms… id = eformsapproval / see Nameeta for password.

8. PerfectForms_Login.png

9. This will bring up the request form.

10. Note Requester role: ADV or Staff (ADVX) or Faculty (ADVX). This will come into play later when adjusting the user in the SHELL application.

11. Check signatures at bottom to see if Supervisor and Registrar have approved.

12. Make note of applicant email, first and last name. Verify the Gid and Pidm is in test and prod banner. (The email will be the matching item between the request form and banner.

13. Special Case: Note: May have to be done by someone with DBA access. If advisor is to be added to Dwtest and the advisor isn't in banner test, then:

  • 13.1 Sign into Banner TEST as BANSECR and assign GOAMTCH object/form to yourself (ex: mpaulus)

14. 13.2 See: https://kb.oakland.edu/uts/BannerJobMigration?highlight=%28DataAdminHowTo%29 on object privilege assignment instructions…

15. 13.3 Go to SPAIDEN , click generate ID

16. 13.4 It will take you to check for a duplicate in GOAMTCH, type in "Person" in the matching source drop down. Page down and enter info. Only need to enter first and last name.

17. 13.5 the click duplicate check, and then if ok, click create new which takes us back to SPAIDEN. The person will be added with a newly generated Gid and Pidm. These need to be changed to match their PROD numbers.

18. 13.6 Go into Banner TEST DB, SPAIDEN table (using SQL*Developer or Toad) and modify newly created record. Type in correct Gid and Pidm matching them to PROD.

19. 13.7 Go into Goremal and add a record for the new person with "test." appended to the front of email.

20. End Special Case

21. For test and/or prod.

22. Sign into classic/web server as yourself then, sudo su - dwadmin

23. Type: bannerextract advisors Gid_number_of_new_advisor

24. Go to DW Web, ADMIN

25. 24.1 Test URL:https://dwjaptst.oakland.edu:8443/dwShell/

26. 24.2 Prod URL:https://dwjapp.oakland.edu:8443/dwShell/

27. ShepentryUsers.png

28. Users tab, look up new person

29. ShepentryUsersEdit.png

30. , chg from ADVX to ADV, chg pw to default for Advisors… See Mike Paulus for pw.

31. Add Group SRNADV

32. Add Key ANYSTUID

33. Save groups and keys…

34. ShepentrySaveKeys.png


D.10. Replace All Scribe Blocks in Production with the ones from Test

Note1: This process replaces ALL Scribe blocks in Prod with the ones from Test.

Note2: Only do this upon request from Registrar's office.

Note3: Entire process must be completed by 8:00 a.m. on Weds. maintenance window.

On Host bdwdapwebfe2

A. Sign into host with your admnet id / pw.

B. sudo su - dwadmin

C. cd datac

D. ls -lart

E. copy the last backup of the Scribe blocks to temp.

  • cp -p reqblocks20180111.tar /tmp/reqblocks20180111.tar

F. chmod 777 /tmp/reqblocks20180111.tar

On Host bdwdapwebfe1

A. Sign into host with your admnet id / pw.

B. sudo su - dwadmin

C. cd datac

D. copy from test to prod (current host) the Scribe backup file.

  • Substitute with your id and the new/latest backup Scribe file name and location.

    scp [email protected] :/tmp/reqblocks20180110.tar reqblocks20180110.tar

E. Load the file into prod.

  • dapblockload R reqblocks20180110.tar

F. Takes a while to run, over an hour sometimes... After completion run: dap16all

G. Update footprint ticket from Registrar office.


D.11. Create Batch Audit PDFs from command line

1. Login to server as dwadmin

2. cd to common directory

3. cp DAP22IDS_toPrintPDF DAP22IDS

4. cd to data directory

5. put ID file in directory. Name it like MYFILE.ids where MYFILE is the name of your file

6. run DAP22IDS job: dap22ids MYFILE.ids

7. PDF files are put in admin/pdfreports directory. We have a GO Anywhere job that copies them to GO Anywhere so customer can pick-up from there.

8. cd to common directory

9. Copy original DAP22IDS file back: cp DAP22IDS10160206 DAP22IDS