CIS 4120 –IC-6-2 Process Modeling Exercise
Conference Registration Process
Scenario
The Society of Business Solutions (SOBS) runs an annual conference for its members and others wishing to attend. They send out mailings and emails that announce the conference and point potential attendees to a web site where they can download and complete a registration form that they then forward to the Society’s conference registration system (process). Below is a description of this process that you’re to model in BPMN.
Prospective attendees (Applicant) complete the registration form (RegForm) and send it via email or fax to the registration system. Upon receipt a RegForm is first stamped with a sequential receipt number and then examined for completeness. If any errors of omission are detected, an email is sent to the Applicant requesting the omitted or incorrect information. The process waits for a reply for seven days. If it’s not received, the RegForm transaction is ended and the Applicant is notified. If corrections are sent, they’re re-checked for errors.
If the RegForm passes this initial review, specific areas are looked at. In sequence …
First if the Applicant is requesting a full-member conference fee (which is lower than if the Applicant is not a current member of the SOBS), his/her name is looked up in the SOBS member database to verify their membership. If it’s found the Applicant is not a member, then an email is sent to them stating that they can either become a member and have this cost added to their conference payment, pay the additional non-member conference fee difference, or withdraw their RegForm application. (It is also possible that the Applicant wishes to dispute that they are indeed a member, but this is a separate process and is treated here the same as withdrawing their application.) An email is sent to the Applicant stating these three options and processing is suspended awaiting their reply. If no reply is given in 7 business days, another email is sent stating that the registration request is being ended and that they will have to reapply with the correct information should they wish to attend the conference.
Depending upon whether the initial membership information was correct, or an update was received based on the email sent for non-membership outlined above, the correct total of the conference fee is calculated.
Then the method of payment is examined. There are two choices provided to the Applicant (on the initial registration form). One is to pay by PayPal. The second is to use Visa. If it’s PayPal, the PayPal external service is checked to see if the transaction is valid and can complete (verification only). Similarly for VISA (verification only), but using a different credit card processing service. In either case, if it’s valid, the processing continues below. If it comes back invalid for the payment service selected, then an email is sent to the Applicant notifying them of this and asking them to provide updated information or a different choice of payment. Again, seven business days are allowed for a response before ending the transaction (with an email sent to that effect). If revised information is received from the Applicant, then the payment validation step is started again with either new information or a different method of payment. (A complication to this is that only two tries are allowed, but this needn’t be modeled).
Upon payment verification, the RegApp information is used to update a conference registration database (which contains the Applicants name, days attending, food preferences, special events and the like).
When all of this has been done, a message is sent to the Applicant letting them know they’re been successfully registered for the conference and providing them with additional, general conference information and a “Thank You” note from the Society president.
To-Do
1. Model the above process using BPMN.