ACES at Duke

1. ACES at Duke Re-inventing a custom web-based student system application

2. Part 1 Making decisions

3. What is ACES? • Duke’s online student system • 24 hour access to registration, grades, bio/demo data, financial data, advising tools

5. What is STORM? • Duke staff and faculty web access to student systems information • Access to student data, class information, applicant information • Ability to perform common course and student data management functions

6. Why? • HTMLAccess (the PeopleSoft product) was immature with unknown performance • IVR wouldn’t be able to handle registration with a PeopleSoft backend • Difficult interface and cumbersome navigation within the PeopleSoft client • Easier to keep customizations outside of PeopleSoft

7. Why? • Desire for added functionality • Registration • Curriculum/Advising • Online Application Entry • Differences across professional schools

9. Bookbag allows for easier advising, less load during registration time, simpler course planning

12. Previous Technology • HAHTSite/VisualBasic front end • Access to PeopleSoft Oracle 8i database via ODBC • Extra tablespace to support added functions • PeopleSoft Message Agent used to save data, so business logic is executed by PeopleSoft Application server

13. Hardware • Cisco CSS load balancer • 3 IBM H70 AIX 4.3 Web Servers (iPlanet) • 3 IBM Netfinity Windows NT backend servers

14. Downside • High support costs for HAHTSite and iPlanet • HAHTsite version no longer supported • Very specialized programming knowledge required for maintenance • Expensive hardware

15. Step 1: Selling Java • A chance to clean up and consolidate code • OO design makes for a simpler design and easier maintenance • Shared code libraries reduce redundant code • A chance to rethink and redesign application pathways based on user feedback

16. jBoss 3.0.3 Jetty 4.2 Jdk 1.4 Jdom b7 Ant Jedit cvs Total Cost: $0 Step 2: Selling Free Tools

17. Step 3: Architecture • Remove business logic from display logic • Achieve greater flexibility and fault tolerance in system design • Facilitate a larger programming team • Maintain as much insulation from PeopleSoft patches and fixes as possible • Increase usability of custom business logic

18. Making the move • Redeveloped business logic to work against PeopleSoft 7.6 • Business logic all contained within a combination of Stateless Session, CMP and BMP Entity EJBs • All business logic returned as XML with an eye toward a future portal • XML converted to HTML with XSLT

19. The Next Steps • Changing business logic to use PeopleSoft 8.1 table changes • Changing message agent calls to use the component interface • Exposing business logic to other Duke applications – generating PDFs, Excel Spreadsheets, reports

20. New Hardware • IBM xSeries rack-mount servers • Inexpensive • Not overkill for the job • Having a farm makes maintenance potentially more tedious, but reduces negative impact of any system failures and increases scalability • Minimal machine room space and lower power requirements

21. The Future • Drop ACES in favor of PS-delivered web client? • Use business logic for Duke-specific functions and incorporate it into the PS web client

22. Part 2 Using the PeopleSoft Component Interface with Java

23. What’s the Component Interface? • PeopleSoft’s way of allowing 3rd party programs access to business logic in version 8.x • Replacement for the version 7.x Message Agent

24. What do you get? • Data entry with the Component Interface simulates entering data directly into the pages • Order of parameters set was not guaranteed under Message Agent • All PeopleCode is fired, but order is not guaranteed

25. Step 1 • Within App Designer, create a component interface mapped to the component you want to access

26. Components in version 8 are like panel groups in version 7

27. Step 2 • PeopleSoft begins generating the component interface by selecting all fields from the component referenced • Fields can be added or removed at will, but less dangerous to leave them all and only set the ones you care about in the client program

29. Step 3 • Build the API (the .jar file to use with the client)

30. Make sure Java Classes Build Box is checked

31. Step 4 • Generate the client template

33. Coding the client application • Add the following imports: import java.io.*; import java.math.*; import psft.pt8.joa.*; import PeopleSoft.Generated.CompIntfc.*; • The joa package comes with PeopleSoft • The .Generated package was built by the previous steps

34. Coding the client application • Setting the server name and port String strAppSeverPath = “//153.4.555.1212:9000"; String strOperatorID = “username"; String strPassword = “password"; • App server path is IP (or DNS name) of application server machine, followed by a : and the JOLT port address

35. Coding the client application • Create the session ISession oSession = API.createSession(); • Connect to the server oSession.connect(1, strAppSeverPath, strOperatorID, strPassword, null); • Get the component IEnrlRequest oEnrlRequest = (IEnrlRequest) oSession.getComponent("ENRL_REQUEST");

36. Coding the client application • Set the keys oEnrlRequest.setEnrlRequestId(“0000000000”); oEnrlRequest.setEmplid(“0039646”); oEnrlRequest.setAcadCareer(“UGRD”); oEnrlRequest.setClassNbr(1022); oEnrlRequest.setEnrlReqAction(“E”); oEnrlRequest.setInstitution(“DUKEU”); oEnrlRequest.setStrm(“0960”);

37. Coding the client application • Create the new request oEnrlRequest.create();

38. Coding the client application • Adding classes IEnrlRequestEnrlReqDetailCollection oEnrlReqDetailCollection = oEnrlRequest.getEnrlReqDetail(); IEnrlRequestEnrlReqDetail oEnrlReqDetail; for (int i = 0; i < oEnrlReqDetailCollection.getCount(); i++){ oEnrlReqDetail = oEnrlReqDetailCollection.item(i); // Add an item to the collection for each class. oEnrlReqDetail.setClassNbr(1022); oEnrlReqDetail.setEnrlReqAction(“E”); }

39. Coding the client application • Save the request oEnrlRequest.save(); • Get the generated enrollment request ID String enrl_request_Id = oEnrlRequest.getEnrlRequestId();

40. Part 3 Design and performance considerations

41. Lessons learned from previous version of ACES • Database tuning (indices, hints) is critical • Network traffic accounts for 50-75% of the time spent waiting for results • Co-locate a web-only PS app server and database • Use connection pooling wherever possible • End-to-end performance testing is critical, the whole is not always the sum of the parts

42. Some EJB Decisions • BMP used much more heavily than CMP for read-only data • Flexible caching algorithms and parameters • Database hits can be greatly minimized on common data at the expense of slightly stale results

43. Some EJB Decisions • Stateless session beans used for up-to-the second read-only data and to save infrequently used data that does not need to be cached • CMP used for frequently updated Duke-specific data controlled entirely through the web application (the bookbag)

44. Consolidation of Machines and Processes • Co-locating EJB, Servlet, and web server on the same machine, and if possible within the same JVM greatly increases performance

45. Connection Pooling • Database • App server connections

46. Exposing EJB methods to clients • Use one stateless session bean to expose the API to EJBs • Reduces the number of JNDI lookups that need to be done to acquire an EJB

47. Investigate Clustering and Cache Options • Jboss is highly configurable • Clustering may decrease performance because of the introduction of network traffic and coordination, but not using clustering can cause skewed results if sticky sessions are not used

48. Contact Information • Matt Young (matt.young@duke.edu) • Richard Outten (richard.outten@duke.edu) • http://www.jboss.org • http://jakarta.apache.com • http://www.jedit.org