ΣΧΕΔΙΑΣΗ ΚΑΙ ΥΛΟΠΟΙΗΣΗ ΔΙΕΠΑΦΗΣ REST ΜΕ ΣΥΣΤΗΜΑ ΔΙΑΧΕΙΡΙΣΗΣ ΡΟΗΣ ΕΡΓΑΣΙΑΣ ΒΡΜΝ

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΗΛΕΚΤΡΟΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΔΙΑΠΑΝΕΠΙΣΤΗΜΙΑΚΟ ΔΙΑΤΜΗΜΑΤΙΚΟ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥΔΩΝ ΣΤΑ «ΠΡΟΗΓΜΕΝΑ ΣΥΣΤΗΜΑΤΑ ΕΠΙΚΟΙΝΩΝΙΩΝ ΚΙ ΥΠΟΛΟΓΙΣΤΩΝ» ΜΕ ΚΑΤΕΥΘΥΝΣΗ «ΔΙΚΤΥΑΚΗ ΥΠΟΛΟΓΙΣΤΙΚΗ -ΗΛΕΚΤΡΟΝΙΚΟ ΕΜΠΟΡΙΟ» Διπλωματική εργασία ΣΧΕΔΙΑΣΗ ΚΑΙ ΥΛΟΠΟΙΗΣΗ ΔΙΕΠΑΦΗΣ REST ΜΕ ΣΥΣΤΗΜΑ ΔΙΑΧΕΙΡΙΣΗΣ ΡΟΗΣ ΕΡΓΑΣΙΑΣ ΒΡΜΝ του ΣΩΤΗΡΙΟΥ ΦΩΤΙΟΥ ΤΣΑΚΙΡΙΔΗ Επιβλέπων Καθηγητής: Νικόλαος Πρωτόγερος Υποβλήθηκε ως απαιτούμενο για την απόκτηση του Μεταπτυχιακού Διπλώματος στα Προηγμένα Συστήματα Επικοινωνιών και Υπολογιστών Φεβρουάριος 2017

2 1

3 Ευχαριστίες Ευχαριστώ πολύ τον Αναπληρωτή Καθηγητή κ. Πρωτόγερο Νικόλαο για τη διατήρηση της άψογης επικοινωνίας που είχε μαζί μου καθ όλη τη διάρκεια εκπόνησης της διπλωματικής μου εργασίας, για την κατανόηση που έδειξε στις δυσκολίες που προέκυψαν και για την καθοδήγησή του, όταν τη χρειάστηκα. Ευχαριστώ, επίσης, την οικογένειά μου που με στήριξαν με όποιο τρόπο μπορούσαν κατά τη διάρκεια αυτής της προσπάθειας. 2

4 ΠΕΡΙΛΗΨΗ Ο τίτλος της παρούσας διπλωματικής εργασίας είναι: Σχεδίαση και Υλοποίηση Διεπαφής REST με Σύστημα Διαχείρισης Ροής Εργασίας BPMN. Μέσω αυτής, αρχικός σκοπός είναι η μοντελοποίηση και η εκτέλεση μιας επιχειρηματικής διαδικασίας μέσω ενός λογισμικού διαχείρισης επιχειρηματικών διαδικασιών και ακολούθως, η αξιοποίηση του REST API που παρέχει ένα τέτοιο λογισμικό, ώστε η διαδικασία να εκτελείται εξ ολοκλήρου στο portal του εκάστοτε οργανισμού, χωρίς να υπάρχει η ανάγκη σύνδεσης στην πλατφόρμα του λογισμικού για την εκτέλεση των διαδικασιών. Αποτελείται από πέντε ενότητες, όπου: - Στην πρώτη ενότητα, αναλύονται έννοιες που σχετίζονται με τη διαχείριση επιχειρηματικών διαδικασιών. - Στη δεύτερη ενότητα, παρουσιάζεται η μεθοδολογία, η οποία ακολουθήθηκε σε αυτή την εργασία. - Στην τρίτη ενότητα, περιγράφεται αναλυτικότερα πως μοντελοποίηθηκε η διαδικασία της «Αίτησης Χορήγησης Αδείας Μέλους ΔΕΠ από το τμήμα Προσωπικού Πανεπιστημίου», πως μετατράπηκε σε εφαρμογή και πως εκτελείται στο περιβάλλον του λογισμικού BPM. Στη συνέχεια, παρουσιάζεται ο τρόπος με τον οποίο υιοθετήθηκε αυτή η λειτουργικότητα μέσω μιας εφαρμογής REST σ έναν εικονικό ιστότοπο, τον οποίο χρησιμοποιούν καθημερινά τα εμπλεκόμενα μέλη στη διαδικασία. - Στην τέταρτη ενότητα, φαίνεται το ερωτηματολόγιο που δόθηκε στους χρήστες για την αξιολόγηση του συστήματος και τα αποτελέσματα που προέκυψαν. - Τέλος, στην πέμπτη ενότητα γίνεται μια σύντομη ανάλυση των πλεονεκτημάτων που προκύπτουν από την υλοποίηση που πραγματοποιήθηκε και αναφέρονται, ακόμη, βελτιώσεις που μπορούν να συμβούν. 3

5 4

6 ΠΙΝΑΚΑΣ ΠΕΡΙΕΧΟΜΕΝΩΝ ΠΕΡΙΛΗΨΗ... 3 ΠΙΝΑΚΑΣ ΠΕΡΙΕΧΟΜΕΝΩΝ... 5 ΕΙΣΑΓΩΓΗ... 7 ΒΙΒΛΙΟΓΡΑΦΙΚΗ ΕΠΙΣΚΟΠΗΣΗ Η διαχείριση επιχειρηματικών διαδικασιών και το πρότυπο BPMN Λογισμικά διαχείρισης επιχειρηματικών διαδικασιών RESTFul Web Services Επικοινωνία μεταξύ BPM και ERP συστημάτων ΜΕΘΟΔΟΛΟΓΙΑ Περιγραφή τρόπου επίτευξης στόχου Μεθοδολογία υλοποίησης ΥΛΟΠΟΙΗΣΗ ΕΦΑΡΜΟΓΗΣ Αρχιτεκτονική εφαρμογής Η βάση δεδομένων «Postgres Database» Εγκατάσταση πλατφόρμας Camunda ΒPM Μοντελοποίηση διαδικασίας-λειτουργικές απαιτήσεις Δημιουργία εφαρμογής Υλοποίηση REST διεπαφής Επεξήγηση τμημάτων κώδικα Script «Check User» Ανάλυση του xml της διαδικασίας Script «Start Instance» Script «Tasklist» Διαδικασία αίτησης αδείας απο μέλος ΔΕΠ μέσω της πλατφόρμας camunda

7 3.8 Διαδικασία αίτησης αδείας μέλους ΔΕΠ μέσω του ιστοτόπου «Compus», χωρίς την ανάγκη εισόδου στην πλατφόρμα Camunda ΑΞΙΟΛΟΓΗΣΗ ΣΥΣΤΗΜΑΤΟΣ Ερωτηματολόγιο αξιολόγησης εφαρμογής Αποτελέσματα ερωτηματολογίου Ανάλυση χρησιμότητας Ευκολία χρήσης Ανάλυση ικανοποίησης ΣΥΜΠΕΡΑΣΜΑΤΑ-ΠΡΟΤΑΣΕΙΣ ΒΙΒΛΙΟΓΡΑΦΙΑ ΠΑΡΑΡΤΗΜΑ Α. Το πρότυπο BPMN Β. Εγκατάσταση Tomcat Γ. Εγκατάσταση CAMUNDA BPM PLATFORM Δ. Το αρχείο XML της μοντελοποιημένης διαδικασίας Ε. Ο κώδικας του Java Project ΣΤ. Κώδικας ιστοτόπου Compus Z. To Ερωτηματολόγιο Αξιολόγησης

8 ΕΙΣΑΓΩΓΗ Σήμερα, η ανταγωνιστικότητα στο επιχειρησιακό περιβάλλον απαιτεί την ικανότητα γρήγορης προσαρμογής στις νέες συνθήκες. Κάτι τέτοιο μπορεί να επιτευχθεί με την ευθυγράμμιση των επιχειρησιακών διαδικασιών και της οργανωτικής στρατηγικής μέσω της τεχνολογίας της πληροφορίας (Information Technology). Προς αυτή την κατεύθυνση, οι επιχειρήσεις επιδιώκουν τη χρήση της Διαχείρισης Επιχειρηματικών Διαδικασιών (Business Process Management), έτσι ώστε να σχεδιάσουν, να μοντελοποιήσουν, να διαχειριστούν, να εκτελέσουν και να ελέγξουν αυτές τις διαδικασίες. Για την μοντελοποίησή τους, έχει δημιουργηθεί το πρότυπο BPMN, σκοπός του οποίου είναι η αναπαράσταση των διαδικασιών μέσω γραφικών αναπαραστάσεων, που θα είναι κατανοητές τόσο από τα επιχειρησιακά στελέχη όσο κι από τα στελέχη πληροφορικής ενός οργανισμού. Τόσο η σχεδίαση όσο και η εκτέλεση των επιχειρησιακών διαδικασιών πραγματοποιείται μέσω αυτών των Συστημάτων Διαχείρισης Επιχειρηματικών Διαδικασιών. Το λογισμικό αυτό συμβάλλει στην καλύτερη συνεργασία των τμημάτων ενός οργανισμού, αλλά και στην πιο αποτελεσματική εξυπηρέτηση των πελάτων. Ωστόσο, για να μπορέσουν να χρησιμοποιήσουν τις λειτουργίες τους, τα στελέχη των επιχειρήσεων πρέπει να εισέλθουν σε ξεχωριστές web εφαρμογές, εκτός του περιβάλλοντος στο οποίο εργάζονται καθημερινά. Σκοπός της παρούσας διπλωματικής εργασίας είναι η διερεύνηση της δυνατότητας ενσωμάτωσης των λειτουργιών ενός συστήματος BPMN στις ήδη υπάρχουσες εφαρμογές στο περιβάλλον λειτουργίας μια επιχείρησης, η οποία να πραγματοποιείται με τη χρήση της τεχνολογίας REST. Για το σκοπό αυτό θα μελετηθεί και θα αναπτυχθεί ένα πρωτότυπο το οποίο θα εφαρμοστεί στη συνέχεια σε ένα τμήμα του Πανεπιστημίου Μακεδονίας. Θα αξιολογηθεί στη συνέχεια η λειτουργία του και θα παρουσιαστούν τα συμπεράσματα από την εφαρμογή και οι δυνατότητες επέκτασης και πλήρους εφαρμογής του στην παραγωγή. 7

9 ΒΙΒΛΙΟΓΡΑΦΙΚΗ ΕΠΙΣΚΟΠΗΣΗ 1.1 Η διαχείριση επιχειρηματικών διαδικασιών και το πρότυπο BPMN Αρχικά, πρέπει να εξεταστεί η έννοια της επιχειρηματικής διαδικασίας, η οποία έχει οριστεί με ποικίλους τρόπους. Ο πιο κοινός ορισμός είναι ο εξής: - Μια Επιχειρηματική Διαδικασία (Business process) είναι μια συλλογή συσχετιζόμενων δομικών δραστηριοτήτων, οι οποίες παράγουν επιθυμητά αποτελέσματα για την επιχείρηση, καθώς και για τους πελάτες της (Λούμος, 2008). Mπορούν να κατηγοριοποιηθούν στις εξής κατηγορίες (Integrated Engineering Group) : 1. Κύριες διαδικασίες, οι οποίες είναι γνωστές και ως αλλεπάλληλες (end-to-end) διαδικασίες. Είναι αυτές που παρέχουν αξία στον πελάτη. 2. Διαδικασίες υποστήριξης, οι οποίες δεν προσφέρουν άμεσα αξία στον πελάτη, αλλά σε άλλους συναλλασσόμενους και μπορούν να είναι ζωτικές για τον οργανισμό. 3. Διαδικασίες διαχείρισης, οι οποίες μετρούν, ελέγχουν και βελτιώνουν συνεχώς την επιχείρηση μέσω των διαδικασιών τους. Ο όρος «Διαχείριση Επιχειρηματικών Διαδικασιών» ( Business Process Management ) αναφέρεται στην προσέγγιση, η οποία βοηθάει τους οργανισμούς και τις εταιρείες να διαχειριστούν καλύτερα τις διαδικασίες τους, να μειώσουν τα κόστη τους, να γίνουν περισσότερο παραγωγικές και να προσθέσουν αξία στη δουλειά τους γενικότερα (Kocbek, Jost, & Polancic, 2015). Τα στάδια διαχείρισης μιας επιχειρηματικής διαδικασίας διαφέρουν ανάλογα και με τις ανάγκες κάποιου πελάτη, αλλά τα κυριότερα από αυτά φαίνονται παρακάτω (Βεργίδης, 2014): 1) Καταγραφή: Το πρώτο στάδιο περιλαμβάνει την καταγραφή των κύριων και επιμέρους διαδικασιών της επιχείρησης. 2) Μοντελοποίηση: Το δεύτερο στάδιο αφορά την αναπαράσταση των ΕΔ με τη χρήση μιας προκαθορισμένης τεχνικής μοντελοποίησης. 3) Εκτέλεση: Το τρίτο στάδιο σχετίζεται με την αυτοματοποίηση της εκτέλεσης μιας ΕΔ. Στο στάδιο αυτό πολλές φορές ενσωματώνεται η χρήση κατάλληλου λογισμικού. 4) Έλεγχος / 8

10 παρακολούθηση: Στο στάδιο αυτό ελέγχεται και αξιολογείται η απόδοση της ΕΔ με βάση συγκεκριμένα κριτήρια. 5) Ανασχεδιασμός / βελτιστοποίηση: Το πιο ωφέλιμο στάδιο. Γίνεται χρήση της συλλογής πληροφοριών και βελτιώνεται ή επανασχεδιάζεται η ΕΔ. H BPMN (Business Process Management and Notation) αποτελεί μία μέθοδο αναπαράστασης επιχειρηματικών διαδικασιών με τη μορφή διαγραμμάτων, που είναι παρόμοια με τα διαγράμματα ροής. Αναπτύχθηκε από την εταιρεία OMG (Object Management Group) και βασικός σκοπός του είναι η παροχή σημειογραφίας, που είναι κατανοητή από όλους τους επιχειρηματικούς χρήστες, από επιχειρηματικούς αναλυτές που σχεδιάζουν τις διαδικασίες μέχρι τους προγραμματιστές, που έχουν την ευθύνη απεικόνισης και υλοποίησης των διαδικασιών αυτών στην τεχνολογία που χρησιμοποιούν. Αποτελείται από γραφικά σύμβολα, τα σημαντικότερα εκ των οποίων επεξηγούνται στο Παράρτημα της παρούσας εργασίας. 1.2 Λογισμικά διαχείρισης επιχειρηματικών διαδικασιών Σε αυτή την υποενότητα, θα περιγραφούν δύο από τα σημαντικότερα εργαλεία που αφορούν τη διαχείριση επιχειρηματικών διαδικασιών. Πριν από αυτό, όμως, πρέπει να αποσαφηνιστούν δύο όροι, που σχετίζονται άμεσα με αυτά και είναι οι εξής: - Process Instance (Στιγμιότυπο διαδικασίας): Αποτελεί μία συγκεκριμένη εκτέλεση μιας διαδικασίας (Process). - Process Definition (Ορισμός διαδικασίας): Είναι ένα επαναχρησιμοποιήσιμο μοντέλο μιας διαδικασίας, το οποίο ορίζει όλες τις συνηθισμένες πτυχές όλων των στιγμιοτύπων μιας διαδικασίας (IBM). Σύμφωνα με την ιστοσελίδα το δημοφιλέστερο σύστημα επιχειρηματικών διαδικασιών αποτελεί το Bizagi BPM, ενώ θα εξεταστεί και το Camunda BPM. 9

11 Bizagi BPM To Bizagi BPM προσφέρει πλήρη αυτοματοποίηση των διαδικασιών, που ξεκινάει από τη σχεδίασή τους και φτάνει μέχρι την εκτέλεσή τους. Αποτελείται από τρία διαφορετικά προϊόντα, που είναι τα εξής (Bizagi, 2014): - Bizagi Modeler, στο οποίο πραγματοποιείται η σχεδίαση της ροής της διαδικασίας από στελέχη business κι όχι απαραίτητα από προγραμματιστές. Επιτρέπει την τεκμηρίωση της διεργασίας με εισαγωγή πληροφοριών σε κάθε επίπεδο της διαδικασίας ή κάθε στοιχείο. Επίσης, παρέχεται η δυνατότητα προσομοίωσης, αποτυπώνοντας τις επιπτώσεις κάθε πιθανής ενέργειας και στοιχείου με πληροφορίες για το χρόνο, το κόστος και τα resources. Σημαντικό πλεονέκτημα αυτού το εργαλείου αποτελεί η δυνατότητα χρήσης του από πολλούς συνεργάτες ταυτόχρονα. - Βizagi Studio, μέσω του οποίου μετατρέπεται το σχέδιο της διαδικασίας σε μια λειτουργική εφαρμογή, χωρίς να χρειαστεί η συγγραφή κώδικα. Όλα τα απαραίτητα βήματα υλοποιούνται μέσω ενός φιλικού προς το χρήστη οδηγού. Το αποτέλεσμα είναι η δημιουργία ενός επιχειρηματικού μοντέλου, που εκτελείται κι ελέγχεται από την Bizagi Engine. - Bizagi Engine, το οποίο ευθύνεται για τη μεταγλώττιση κάθε στοιχείου που δημιουργήθηκε στα προηγούμενα στάδια και η δημιουργία μιας πύλης εργασίας, στην οποία θα μπορούν να έχουν πρόσβαση όλοι οι συμμετέχοντες της διαδικασίας. Αποτελείται από κάποιες επιμέρους «μηχανές», τη Workflow Engine, την Business Rule Engine και την Assignations Engine, με τις οποίες ο τελικός χρήστης δεν έρχεται σ επαφή. Ο τελικός χρήστης ολοκληρώνει τις διάφορες διεργασίες του μέσω του Bizagi Work Portal. Μια σημαντική διαφορά αυτού σε σχέση με τα προηγούμενα εργαλεία είναι ότι απαιτείται πληρωμή για να χρησιμοποιηθεί από κάποιο οργανισμό. 10

12 Εικόνα 1.1:To Bizagi Work Portal Camunda BPM Παρακάτω, φαίνονται τα σημαντικότερα δομικά στοιχεία του Camunda, μαζί με κάποιους ρόλους χρηστών και πως αυτοί εμπλέκονται στη χρήση τους. Εικόνα 1.2: :Η αρχιτεκτονική του Camunda (Πηγή: Camunda, 2015) Στο κέντρο του σχήματος, υπάρχει η (Process) Engine, η οποία αποτελεί και τον πυρήνα του συστήματος. Είναι μια βιβλιοθήκη JAVA, η οποία ευθύνεται για την εκτέλεση BPMN 11

13 2.0 διαδικασιών κι εργασιών ροής και χρησιμοποιεί μια σχεσιακή βάση δεδομένων για διατήρηση αυτών (Camunda, 2015). Οι εφαρμογές Cockpit, Admin και Tasklist θα παρουσιαστούν αναλυτικότερα παρακάτω. Η σχεσιακή βάση δεδομένων που θα χρησιμοποιηθεί από την process engine πρέπει, αρχικά, να δημιουργηθεί και στη συνέχεια, να πραγματοποιηθεί κατάλληλη παραμετροποίηση, ώστε να ρυθμιστεί η επικοινωνία με αυτήν. Εικόνα 1.3: Μια τυπική όψη του Cockpit Η πλατφόρμα Camunda αποτελείται από τρεις εφαρμογές: - Cockpit, που είναι και η εφαρμογή που βλέπει ο χρήστης, όταν συνδέεται στην πλατφόρμα. Δίνει τη δυνατότητα ενημέρωσης για τις διαδικασίες που έχουν εισαχθεί, καθώς και διαχείρισης των στιγμιοτύπων αυτών. Επιλέγοντας κάποια από αυτές, μπορεί ο χρήστης να δει περισσότερες πληροφορίες για τα στιγμιότυπά της, για παράδειγμα τις μεταβλητές που περιέχουν ή το σημείο στο οποίο βρίσκεται η διαδικασία, ενώ ακόμη δύναται να προχωρήσει σε ενέργειες επί των στιγμιοτύπων, όπως η ακύρωσή τους. - Tasklist, που αποτελεί ίσως και την πιο βασική εφαρμογή για τον τελικό χρήστη. Ο χρήστης, εδώ, μπορεί να προχωρήσει στις εξής ενέργειες: 1. Ξεκίνημα ενός νέου instance μιας διαδικασίας 2. Ανάθεση εργασιών (user tasks σε χρήστες) 12

14 3. Ορισμός καταληκτικής ημερομηνίας σε tasks 4. Πραγματοποίηση ενεργειών επί των user tasks Εικόνα 1.4:Μια τυπική όψη του Tasklist - Admin, που είναι η εφαρμογή μέσω της οποίας o διαχειριστής μπορεί να δημιουργήσει νέους χρήστες, που μπορούν να συμμετάσχουν στο σύστημα και τις διαδικασίες, να ορίσει ομάδες χρηστών και τα δικαιώματα που μπορούν να έχουν. Εικόνα 1,5:Μια τυπική όψη του Admin 13

15 1.3 RESTFul Web Services Πρέπει, αρχικά, να οριστεί η έννοια του web service. Σύμφωνα με την IBM, web service (ή υπηρεσία ιστού) είναι ένα σύνολο προτύπων που επιτρέπει τη διαλειτουργική επικοινωνία μεταξύ ετερογενών διαδικασιών και συστημάτων πληροφορικής (ΙΒΜ). H αρχιτεκτονική REST αποτελεί μία κατηγορία τέτοιου service. O όρος REST (Representational State Transfer) συστήθηκε από τον Roy Fielding. Η αρχιτεκτονική REST είναι μία client server αρχιτεκτονική, κατά την οποία ο client στέλνει κάποια αιτήματα στο server, ο server τα επεξεργάζεται και αποκρίνεται αναλόγως στον client (Mumbaikar & Padiya, 2013). Τα αιτήματα και οι αποκρίσεις έχουν να κάνουν με τη μεταφορά της αναπαράστασης κάποιων πόρων. Ο πόρος είναι κάτι το οποίο αναγνωρίζεται από ένα URI. Η αναπαράσταση του πόρου θεωρείται ένα «έγγραφο», το οποίο αποτυπώνει την τρέχουσα κατάσταση ενός πόρου. Για τη δημιουργία των αιτημάτων, χρησιμοποιούνται ρήματα, όπως POST, PUT, DELETE, GET, καθένα από τα οποία αποτελεί μία HTTP μέθοδο. Από την άλλη, στις αποκρίσεις επισημαίνεται η έκβαση του αιτήματος με κάποιους κωδικούς και μια σύντομη περιγραφή, ενώ σε κάποιες περιπτώσεις κι εφόσον είναι επιτυχές ένα αίτημα, περιέχουν τα δεδομένα που ζητήθηκαν σε μορφή JSON. H αρχιτεκτονική SOAP είναι η έτερη κατηγορία Web Services, η οποία βασίζεται κυρίως στην XML για την ανταλλαγή μηνυμάτων κι αναπτύχθηκε από τη Microsoft για ν αντικαταστήσει παλαιότερες τεχνολογίες, όπως η DCOM και η CORBA. Μειονέκτημά της αποτελεί το γεγονός ότι η XML που χρησιμοποιείται για την επικοινωνία μπορεί να γίνει ιδιαίτερα πολύπλοκη, ενώ από την άλλη βασικό της πλεονέκτημα είναι η διαχείριση σφαλμάτων, καθώς σε περίπτωση που το αίτημα περιέχει κάποιο πρόβλημα, παρέχονται πληροφορίες ώστε να μπορέσει ο χρήστης να το διορθώσει (Mueller, 2013). Δεν απαιτείται το πρωτόκολλο επικοινωνίας HTTP, ενώ τα μηνύματα επικοινωνίας έχουν συνήθως μεγαλύτερη έκταση σε σχέση με αυτά της REST αρχιτεκτονικής. Τα κυριότερα οφέλη της REST αρχιτεκτονικής είναι τα εξής (Hamad, Saad, & Abed, 2009) (Albreshne, Fuhrer, & Pasquier, 2009): 1) Προσφέρει καλύτερους χρόνους απόκρισης λόγω της δυνατότητας «αποθήκευσης σε κρυφή μνήμη» (caching) που προσφέρει. 14

16 2) Η πρόσβαση σε οποιαδήποτε εφαρμογή και οποιοδήποτε πόρο (resource) μπορεί να πραγματοποιηθεί μέσω ενός απλού περιηγητή (browser), γι αυτό κι απαιτείται σε μικρότερο βαθμό η ανάπτυξη λογισμικού πελάτη εξυπηρετητή σε σχέση με άλλες προσεγγίσεις. 3) Η αναζήτηση για Web resources πραγματοποιείται χωρίς τη χρήση κάποιου ξεχωριστού μηχανισμού. 4) Βασίζεται σε πολλά γνωστά πρότυπα, μεταξύ των οποίων η XML, URI, HTTP και JSON, που τη συνιστά απλή και κατανοητή. 5) Μπορεί να χρησιμοποιηθεί ανεξάρτητα προγραμματιστικής γλώσσας και λειτουργικού συστήματος. 6) Βελτιώνεται η επεκτασιμότητα του εξυπηρετητή, καθώς είναι μειωμένη η ανάγκη διατήρησης της κατάστασης επικοινωνίας. 1.4 Επικοινωνία μεταξύ BPM και ERP συστημάτων Πολλές παγκοσμίου φήμης επιχειρήσεις στηρίζονται στην BPMN για τη σχεδίαση διαδικασιών, ώστε να επιτύχουν μια σειρά από στρατηγικούς στόχους. Η Coca Cola αποτελεί μία από τις πιο χαρακτηριστικές περιπτώσεις τέτοιων επιχειρήσεων, η οποία παρουσίασε το 2013 στα πλαίσια του συνεδρίου «Innovation World» στο San Francisco τους τρόπους με τους οποίους αξιοποίησε και υιοθέτησε τη BPMN στις διαδικασίες της (Burgstaller, 2013). Η ανάγκη για τη χρήση BPM στα πλαίσια ενός ERP συστήματος προέκυψε, καθώς η εταιρεία διαθέτει 250 ανεξάρτητους εταιρικούς συνεργάτες σε όλο τον κόσμο για την εμφιάλωση των προϊόντων της κι επομένως, θεωρήθηκε κρίσιμο να διαμορφώνεται ένα κοινό μοντέλο λειτουργίας, το οποίο να προωθείται προς αυτούς τους συνεργάτες και να προσαρμόζεται από αυτούς ανάλογα με τις τοπικές ανάγκες (Sandy, 2013). Πιο συγκεκριμένα, χρησιμοποιεί το εργαλείο επιχειρηματικών διαδικασιών ARIS, το οποίο συνδέεται με το σύστημα ERP, «SAP». To μοντέλο αυτό ονομάστηκε «Coke One» και είναι διαμορφωμένο έτσι, ώστε στο «ARIS» να πραγματοποιείται ο ορισμός και η ανάλυση των επιχειρησιακών διαδικασιών, που λαμβάνουν χώρα κατά τις φάσεις σχεδιασμού κι ανάλυσης των απαιτήσεων, ενώ ο τεχνικός σχεδιασμός και η υλοποίηση πραγματοποιείται στο SAP. 15

17 Ωστόσο, δεν παρουσιάστηκαν τεχνικές λεπτομέρειες για τον τρόπο με τον οποίο γίνεται η επικοινωνία των δύο συστημάτων. Σε μελέτη που πραγματοποιήθηκε το 2012 στο πανεπιστήμιο «Pontificia Universidad Javeriana», παρουσιάστηκαν διάφορες προσεγγίσεις για τους τρόπους με τους οποίους μπορούν να επικοινωνήσουν ένα BPM σύστημα μ ένα ERP σύστημα. Στο συγκεκριμένο πανεπιστήμιο, είχε δημιουργηθεί μια εικονική εταιρεία με το όνομα «CIM», της οποίας αντικείμενο ήταν η παραγωγή μεταλλικών στοιχείων και για την υποστήριξη διαφόρων διαδικασιών, όπως οι πωλήσεις, η διανομή και ο σχεδιασμός της παραγωγής, επέλεξαν την ενσωμάτωση ενός SAP R/3 συστήματος. Αργότερα, θεωρήθηκε ότι κάποιες κρίσιμες διαδικασίες έπρεπε να αυτοματοποιηθούν και γι αυτό το λόγο, επιβαλλόταν η ενοποίησή του με ένα BPM σύστημα (της εταιρείας Bizagi). Η διαδικασία πώλησης ήταν αυτή που έπρεπε να αυτοματοποιηθεί και μια από τις δραστηριότητες που περιλαμβάνει αφορά την ταυτοποίηση ενός πελάτη. Η προσέγγιση που παρουσιάζεται για την ενοποίηση των δύο συστημάτων είναι η εξής (Aguirre-Mayorga, Carreño-Vargas, Vega-Mejía, Castellanos-Arias, & Hernández-Martínez, 2012): 1. Η δραστηριότητα της «Ταυτοποίησης Πελάτη», που εκτελείται στο περιβάλλον του Bizagi, επικοινωνεί μ έναν προσαρμογέα web service, ζητώντας την κατανάλωση ενός BAPI (αποτελούν προγραμματιστικές διεπαφές, που επιτρέπουν σε εξωτερικές εφαρμογές την πρόσβαση σε διαδικασίες και δεδομένα ενός SAP R/3 συστήματος), που βρίσκεται στην πλευρά του ERP. 2. Ο προσαρμογέας, που έχει λάβει τις απαραίτητες παραμέτρους από την παραπάνω δραστηριότητα, τις μετασχηματίζει σε XML μήνυμα, σύμφωνα με το πρότυπο που ορίζει το SAP Web Service. 3. Εφόσον ο προσαρμογέας «καταναλώσει» το SAP Web Service, αυτό με τη σειρά του μετασχηματίζει τις XML πληροφορίες, έτσι ώστε να καλέσει σωστά το BAPI. 4. Tο BAPI κάνει όλες τις απαραίτητες ενέργειες στην πλευρά του ERP για να λάβει τις πληροφορίες που ζητήθηκαν, οι οποίες θα μετασχηματιστούν από το SAP Web Service σε XML μορφή και θα σταλθούν πίσω στον προσαρμογέα. 16

18 5. Ο προσαρμογέας, αφού λάβει το XML μήνυμα, το διαμορφώνει σε σχήμα κατανοητό για το BPM σύστημα και για τις παραμέτρους που ζητήθηκαν. Στο σχήμα, φαίνεται ο τρόπος επικοινωνίας των δύο συστημάτων. Εικόνα 1.6:: Η επικοινωνία μεταξύ SAP R/3 και Bizagi BPM (Πηγή: Aguirre-Mayorga, Carreño-Vargas, Vega-Mejía, Castellanos-Arias, & Hernández-Martínez, 2012) Μια άλλη προσέγγιση για την επικοινωνία μεταξύ BPM και ERP συστημάτων παρουσιάστηκε από τους Wasser και Lincoln (Wasser & Lincoln, 2009). H μέθοδος τους ονομάστηκε «ProcessGene Connector» κι, όπως υποστηρίζουν, επιτρέπει την απευθείας επικοινωνία επιχειρησιακών μοντέλων με συστήματα ενδοεπιχειρησιακού σχεδιασμού, χωρίς να χρειάζεται ο χρήστης να διαθέτει εκτεταμένες τεχνικές γνώσεις. Όπως και η προηγούμενη, έτσι κι αυτή η προσέγγιση βασίζεται στην αρχιτεκτονική SOA (Service oriented Architecture). Σε αρχική φάση, γίνεται η μοντελοποίηση των διαδικασιών από μια ομάδα ειδικών, η οποία φροντίζει να συμπεριλάβει σε αυτές χρήστες-«κλειδιά» κι επιχειρηματικούς αναλυτές. Ακολουθεί η αντιστοίχιση της κάθε διαδικασίας με μια λειτουργία του ERP συστήματος. Σε αυτή τη φάση, συμμετέχουν επιστήμονες της πληροφορικής, οι οποίοι έχουν γνώση του ERP συστήματος και πρέπει ν αναλάβουν την προσαρμογή του, ώστε να συνάδει με τον ορισμό των επιχειρηματικών διαδικασιών που δημιουργήθηκαν προηγουμένως. Εφόσον ολοκληρωθεί η επικοινωνία των δύο συστημάτων, ο τελικός χρήστης μπορεί να επιλέξει μία δραστηριότητα μέσα στο BPM σύστημα. Τότε, το Web Service που υλοποιήθηκε παραπάνω, ανακτά μία λίστα μενού από το ERP σύστημα, η οποία παρουσιάζεται στο χρήστη. Ο χρήστης επιλέγει το ανάλογο μενού, που οδηγεί στη δημιουργία ενός συνδέσμου μεταξύ της BPM δραστηριότητας και της ERP λειτουργίας. Μέσω αυτού του συνδέσμου, ο χρήστης μπορεί ανά πάσα στιγμή να οδηγηθεί στη σχετική, με τη BPM δραστηριότητα, περιοχή του ERP συστήματος. Στη βιβλιογραφία, δεν εντοπίστηκε κάποια υλοποίηση, κατά την οποία η επικοινωνία μεταξύ ενός BPM κι ενός ERP συστήματος να γίνεται μέσω RESTful Web Services και γι αυτό, μέσω της παρούσας διπλωματικής εργασίας, επιδιώκεται η παρουσίαση αυτής της προσέγγισης με 17

19 στόχο την εκμετάλλευση των πλεονεκτημάτων που παρουσιάζει η REST αρχιτεκτονική, τα οποία παρουσιάστηκαν στην ενότητα

20 ΜΕΘΟΔΟΛΟΓΙΑ 2.1 Περιγραφή τρόπου επίτευξης στόχου Η επίλυση του προβλήματος της παρούσας διπλωματικής εργασίας θα βασιστεί σε δύο βασικούς πυλώνες και είναι οι εξής: α) Αρχικά, πρέπει να σχεδιαστεί μια επιχειρηματική διαδικασία, η οποία θα βασίζεται σε κάποια αντίστοιχη μιας επιχείρησης ή ενός οργανισμού. Η διαδικασία αυτή θα πρέπει να μπορεί να εκτελείται μέσω ενός συστήματος διαχείρισης επιχειρηματικών διαδικασιών και θα πρέπει να εμπλέκει διαφορετικά τμήματα ενός οργανισμού. Τα συγκεκριμένα τμήματα θα πρέπει να ολοκληρώνουν τις ενέργειες που αφορούν την επιχειρηματική διαδικασία αποκλειστικά μέσω του συστήματος διαχείρισης κι όχι με άλλους τρόπους (π.χ. τηλεφωνικά). β) Σκοπός είναι η ολοκλήρωση των ενεργειών από τους εμπλεκόμενους χρήστες μέσω ενός portal που χρησιμοποιούν καθημερινά και να μην υπάρχει η ανάγκη εισόδου στο περιβάλλον ενός συστήματος διαχείρισης επιχειρηματικών διαδικασιών. Γι αυτό θα αξιοποιηθεί η τεχνολογία REST, η οποία καθιστά δυνατή την επικοινωνία εφαρμογών μέσω ενός δικτύου. Στην επόμενη ενότητα, παρουσιάζονται αναλυτικά τα βήματα που θα ακολουθηθούν για την ικανοποίηση των παραπάνω στόχων. 2.2 Μεθοδολογία υλοποίησης Βήμα 1: Εξέταση εργαλείων μοντελοποίησης Αρχικά, θα πρέπει να γίνει σύγκριση διαφορετικών λογισμικών διαχείρισης επιχειρηματικών διαδικασιών. Τα κριτήρια στα οποία θα βασιστεί αξιολόγηση είναι τα εξής: - Λειτουργία ανοιχτού κώδικα - Παροχή εργαλείου μοντελοποίησης διαδικασιών - Ύπαρξη REST API - Επίπεδο παραμετροποίησης - Φιλικότητα προς το χρήστη - Java-based 19

21 Βήμα 2: Εγκατάσταση εργαλείου BPM κι αξιολόγησή του Αφού προκύψει το κατάλληλο εργαλείο BPM από το παραπάνω βήμα, θα ακολουθήσει η μελέτη των απαιτήσεων εγκατάστασής του. Οι πιο κοινές απαιτήσεις των εργαλείων BPM στις οποίες πρέπει να δοθεί προσοχή, είναι οι εξής: 1) Οι βάσεις δεδομένων, με τις οποίες είναι συμβατές. Σε αυτές αποθηκεύονται οι διαδικασίες και οι διάφορες λεπτομέρειες, που αφορούν την αυτοματοποίησή τους. 2) Οι διακομιστές εφαρμογών (application servers), στους οποίους μπορούν να εγκατασταθούν. Πρέπει, λοιπόν, να ακολουθήσει η εγκατάσταση της κατάλληλης βάσης δεδομένων και του application server. Πλέον, είναι εφικτή η λήψη κι εγκατάσταση του εργαλείου BPM στον application server και η σύνδεση του με τη βάση δεδομένων. Βήμα 3: Μοντελοποίηση διαδικασίας Ακολούθως, θα πραγματοποιηθεί έρευνα στο διαδίκτυο για τις περιπτώσεις, κατά τις οποίες μέλη του προσωπικού ενός πανεπιστημίου ή φοιτητές χρειάζεται ν απευθυνθούν είτε στις γραμματείες των τμημάτων είτε σε άλλες υπηρεσίες για την ικανοποίηση διαφόρων αιτημάτων. Τέτοιου είδους διαδικασίες είναι οι εξής: 1. Χορήγηση κάρτας σίτισης στους φοιτητές από το τμήμα Φοιτητικής Μέριμνας 2. Χορήγηση άδειας σε μέλη ΔΕΠ από το τμήμα Προσωπικού 3. Προκήρυξη θέσης μέλους ΔΕΠ από το τμήμα Προσωπικού 4. Έκδοση κάρτας μέλους από τη Βιβλιοθήκη του Πανεπιστημίου Εφόσον επιλεγεί μια διαδικασία, θα πρέπει να μοντελοποιηθεί σε γλώσσα BPMN. Δηλαδή, θα πρέπει σε διάγραμμα BPMN ν απεικονιστούν οι διεργασίες που περιλαμβάνονται, οι χρήστες που εμπλέκονται και οι αποφάσεις που πρέπει να ληφθούν, ανάλογα με το στάδιο της διαδικασίας. Οι χρήστες που θα περιληφθούν στη διαδικασία πρέπει να δημιουργηθούν και στην πλατφόρμα BPM, με κατάλληλα στοιχεία εισόδου και δικαιώματα. 20

22 Bήμα 4: Δημιουργία εφαρμογής Το αρχείο που θα δημιουργηθεί από το παραπάνω βήμα πρέπει να ενταχθεί σ ένα Maven Project στο περιβάλλον Eclipse. Εκεί, θα πρέπει να γραφεί κώδικας σε γλώσσα Java, ώστε να γίνει επεξεργασία διαφόρων μεταβλητών και να προστεθεί επιπλέον λειτουργικότητα στη διαδικασία. Από το project αυτό θα παραχθεί μία εφαρμογή τύπου war, η οποία θα εγκατασταθεί στον Application Server. Βήμα 5: Πιλοτική λειτουργία εφαρμογής μέσω του περιβάλλοντος BPM Στη συνέχεια, θα εξεταστεί η σωστή λειτουργία της εφαρμογής μέσα από το περιβάλλον του BPMN. Θα πρέπει να ελεγχθεί αν η ενέργεια που πραγματοποιεί κάθε χρήστης έχει τα επιθυμητά αποτελέσματα και να καταγραφούν πιθανές ελλείψεις, ώστε να πραγματοποιηθούν βελτιώσεις στο σχεδιασμό κι εκτέλεση της διαδικασίας. Βήμα 6: Εγκατάσταση WAMP και Wordpress Στόχος αυτού του βήματος είναι η ανάδειξη ενός τρόπου έναρξης κι ολοκλήρωσης της παραπάνω διαδικασίας μέσα από το portal που χρησιμοποιούν καθημερινά. Εφόσον δεν έχουμε δικαίωμα παρέμβασης στο ιστότοπο του Compus ( του Πανεπιστημίου Μακεδονίας, υπάρχει η ανάγκη υλοποίησης ενός ιστοτόπου, που θα προσομοιώνει την πύλη ηλεκτρονικής μάθησης Compus. Κάτι τέτοιο μπορεί να συμβεί μέσω της πλατφόρμας Wordpress, στην οποία μπορεί να κατασκευαστεί μια ιστοσελίδα, όπου θα θεωρήσουμε ότι συνδέονται οι διάφοροι χρήστες της διαδικασίας για την τακτοποίηση των καθημερινών τους υποχρεώσεων. Προαπαιτούμενο για την λειτουργία του Wordpress είναι η ύπαρξη ενός WAMP Server. Σε αυτόν πρέπει να δημιουργηθεί βάση, μέσω του phpmyadmin, για την αποκλειστική χρήση της από το Wordpress. Θα ακολουθήσει η εγκατάσταση της πλατφόρμας Wordpress στον WAMP Server και σύνδεση με τη βάση δεδομένων που υλοποιήθηκε. Μετά την επιτυχή εγκατάσταση, θα πρέπει να δημιουργηθούν τόσοι χρήστες όσοι δημιουργήθηκαν στην πλατφόρμα BPM, φροντίζοντας να έχουν τα ίδια username. Μέσω REST ερωτήματος προς την process engine, θα πραγματοποιηθεί έλεγχος για την ομάδα 21

23 (δηλαδή αν είναι μέλος ΔΕΠ ή υπάλληλος κάποιου τμήματος) στην οποία ανήκει ο χρήστης που έχει πραγματοποιήσει είσοδο. Βήμα 7: Σύγγραφη κώδικα για την υλοποίηση των REST ερωτημάτων Αρχικά, απαιτείται η μελέτη των REST μεθόδων, που παρέχει το REST API του εργαλείου BPM και για την καλύτερη κατανόησή τους, μπορούν να δοκιμαστούν μέσω ενός REST Client, όπως ο «Postman», που είναι διαθέσιμος στον Google Chrome. Η πραγματοποίηση των REST ερωτημάτων από την ιστοσελίδα στο Wordpress στην process engine μπορεί να γίνει με χρήση κώδικα PHP. Στόχος είναι η παραγωγή των ίδιων φορμών που έπρεπε να συμπληρώσουν οι χρήστες στο περιβάλλον του BPM και η εμφάνιση των ίδιων αποτελεσμάτων. Ο ορισμός της διαδικασίας περιέχεται στο αρχείο xml, που δημιουργήθηκε κατά τη μοντελοποίηση της διαδικασίας, επομένως στόχος είναι η λήψη του αρχείου αυτού μέσω REST ερωτήματος, η ανάλυσή του και η παραγωγή κώδικα από αυτό. Φυσικά, θα πρέπει να πραγματοποιηθούν κι άλλες κλήσεις REST, αναλόγως με την επιδιωκόμενη λειτουργικότητα της διαδικασίας. Bήμα 8: Εκτέλεση διαδικασίας μέσω της ιστοσελίδας «Compus» Μετά την ολοκλήρωση όλων των απαραίτητων ρυθμίσεων, θα πρέπει να μπορεί να εκτελείται η διαδικασία μέσα από την ιστοσελίδα «Compus». Τα δεδομένα που λαμβάνονται από τα REST ερωτήματα πρέπει να είναι σωστά και να παρουσιάζονται στον τελικό χρήστη με ευδιάκριτο τρόπο. Επίσης, η ροή της διαδικασίας, οι ενέργειες των χρηστών και τ αποτελέσματα που προκύπτουν από αυτές δεν πρέπει ν αποκλίνουν σε σχέση με την εκτέλεση της διαδικασίας μέσω του περιβάλλοντος BPM. Βήμα 9: Αξιολόγηση εφαρμογής από τελικούς χρήστες και ανάλυση συμπερασμάτων Στη τελευταία φάση, πρέπει η εφαρμογή να ελεγχθεί από τελικούς χρήστες, η οποίοι θα αποτυπώσουν την εμπειρία τους σ ένα ερωτηματολόγιο που θα τους δοθεί. Η μέθοδος που θ ακολουθηθεί είναι η «αξιολόγηση δοκιμής χρηστών» και σκοπός είναι ν αναδειχθεί ο βαθμός ικανοποίησής τους από την εφαρμογή, αλλά και η καταγραφή πιθανών προτάσεων 22

24 που θα μπορούσαν να βελτιώσουν το υπάρχον σύστημα. Θα πρέπει να επιλεγούν άτομα υψηλού μορφωτικού επιπέδου, ώστε να αντιπροσωπεύουν όσο γίνεται καλύτερα τα μέλη/υπαλλήλους ενός πανεπιστημίου. Το ερωτηματολόγιο θα περιέχει ερωτήσεις τύπου Likert, δηλαδή μιας κλίμακας εκτίμησης απόψεων ή συμπεριφοράς. Τα κριτήρια βάσει των οποίων θα πρέπει να βαθμολογήσουν την εφαρμογή είναι τα εξής: - Χρησιμότητα - Ικανοποίηση - Ευκολία χρήσης Αρχικά, θα πρέπει να εκτελέσουν τη διαδικασία μέσα από το περιβάλλον BPM (θα χρειαστεί να υποβληθούν σε μια σύντομη εκπαίδευση πάνω σε αυτό, σε περίπτωση που δεν έχουν προηγούμενη εμπειρία). Ακολούθως, την ίδια διαδικασία θα την ξεκινήσουν και ολοκληρώσουν μέσω της ιστοσελίδας «Compus». Για να κριθεί επιτυχημένο το εγχείρημα της παρούσας διπλωματικής εργασίας, πρέπει οι χρήστες να μπορούν να εκτελούν τη διαδικασία μέσα από την ιστοσελίδα «Compus»: - Χωρίς προβλήματα και τα αποτελέσματα να είναι πανομοιότυπα με αυτά που προκύπτουν στο περιβάλλον BPM - Με ικανοποιητική ταχύτητα - Με ικανοποίηση για το γεγονός ότι δε χρειάζεται να μπουν σ ένα εξωτερικό site (το περιβάλλον BPM) για την ολοκλήρωση της διαδικασίας Στη συνέχεια, τα αποτελέσματα θα αναλυθούν μέσω της στατιστικής μεθόδου των «κατανομών συχνότητας», ώστε να εξαχθούν χρήσιμα συμπεράσματα από αυτά. 23

25 ΥΛΟΠΟΙΗΣΗ ΕΦΑΡΜΟΓΗΣ 3.1 Αρχιτεκτονική εφαρμογής Στην παρούσα ενότητα θα παρουσιαστεί η αρχιτεκτονική της εφαρμογής που υλοποιήθηκε. Στην εικόνα 3.1 φαίνεται το κεντρικό διάγραμμα της εφαρμογής. Για την εγκατάσταση του Camunda, απαιτήθηκε η λήψη ενός application server, δηλαδή ενός framework λογισμικού, το οποίο θα επιτρέπει τη δημιουργία web εφαρμογών και την εκτέλεση τους σε αυτόν. Εικόνα 3.1: Αρχιτεκτονική της εφαρμογής 24

26 Σύμφωνα με τις απαιτήσεις εγκατάστασης της πλατφόρμας Camunda BPM, ένας από τους καταλληλότερους αποτελεί ο Apache Tomcat, έκδοσης νεότερης της 7.0, γι αυτό κι επιλέχθηκε η χρήση του Apache Tomcat Για τη λειτουργία του, χρειάζεται απλά το κατέβασμα του σχετικού.zip αρχείου από το site: Χρειάστηκε μια σειρά από τροποποιήσεις σε διάφορα αρχεία και φάκελους του Server, ώστε να «φιλοξενηθεί» χωρίς προβλήματα σε αυτόν το Camunda, οι οποίες περιγράφονται στις επόμενες ενότητες και στο Παράρτημα. Για λόγους ευκολίας, θα αναφερόμαστε στον φάκελο που εγκαταστάθηκε ο Apache Tomcat με το pattern $TOMCAT_HOME. H πλατφόρμα Camunda υποστηρίζει μια μεγάλη γκάμα βάσεων δεδομένων, εκ των οποίων επιλέχτηκε η PostgreSQL, έκδοσης 9.5. Τα αρχεία εγκατάστασης της βρίσκονται στο σύνδεσμο: Μετά την εγκατάστασή της, ακολούθησε: - η δημιουργία χρήστη, με όνομα χρήστη «camunda» κι έναν κωδικό πρόσβασης - η δημιουργία βάσης με το όνομα «process-engine6» και - η παροχή όλων των δικαιωμάτων στο χρήστη «camunda» επί αυτής της βάσης. Δεν απαιτείται η δημιουργία πινάκων εντός αυτής από τον χρήστη, καθώς αυτοί θα παραχθούν αυτόματα. Σύμφωνα με το εγχειρίδιο εγκατάστασης του camunda, όταν πραγματοποιείται για πρώτη φόρα deploy του Camunda web application, δημιουργείται αυτόματα ένας φάκελος με τα περιεχόμενα της εφαρμογής. Εντός αυτού, στο φάκελο WEB- INF/lib, υπάρχει το αρχείο camunda-engine jar, στο οποίο περιέχονται SQL Scripts για τη δημιουργία των πινάκων στη βάση που χρησιμοποιεί η process-engine και που ορίσαμε στο αρχείο $ΤΟΜCAT_HOME/conf/server.xml. Μάλιστα, υπάρχει ξεχωριστό SQL script για κάθε υποστηριζόμενη βάση δεδομένων. Στην περίπτωση μας, εκτελούνται τα scripts που αφορούν την postgresql και με τον τρόπο αυτό γεμίζει η βάση που δημιουργήσαμε με όλους τους απαραίτητους πίνακες για τη σωστή λειτουργία του Camunda. Οι πίνακες που δημιουργήθηκαν στη βάση δεδομένων περιγράφονται αναλυτικά στην επόμενη ενότητα. 25

27 3.2 Η βάση δεδομένων «Postgres Database» Στην ενότητα 3.1, παρουσιάστηκε συνοπτικά η διαδικασία δημιουργίας της βάσης δεδομένων, η οποία αντιστοιχεί στη βάση «Postgres Database» της αρχιτεκτονικής. Όπως φαίνεται και παρακάτω, έχουν δημιουργηθεί 32 πίνακες δεδομένων σε αυτή, αλλά θα περιοριστούμε στην περιγραφή των πιο σημαντικών. Εικόνα 3.2: Οι πίνακες της βάσης δεδομένων 26

28 i) Πίνακας ACT_RE_PROCDEF Εικόνα 3.3: Τα πεδία του πίνακα ACT_RE_PROCDEF Αποτελείται από έντεκα πεδία, όπως αυτά φαίνονται στην εικόνα. Περιέχει όλους τους ορισμούς διαδικασιών (process definition) που έχουν γίνει deploy στον Tomcat Server. Για κάθε έκδοση του process definition, υπάρχει διαφορετική εγγραφή στο συγκεκριμένο πίνακα. Καθεμιά έκδοση από αυτές χαρακτηρίζεται μοναδικά από το Id, το οποίο είναι τύπου char (χαρακτήρας). Η τιμή του πεδίου resource_name προσδιορίζεται από το όνομα αρχείου bpmn της διαδικασίας, ενώ το πεδίο name χαρακτηρίζεται από το όνομα της διαδικασίας, όπως αυτό έχει οριστεί στο παραπάνω αρχείο. To πεδίο category αναφέρεται στο σχήμα (schema) BPMN, το οποίο χρησιμοποιήθηκε για τη δομή του process. Τέλος, το πεδίο version αναφέρεται στην έκδοση αυτού του process definition. Νέα έκδοση δημιουργείται, όταν γίνει deploy μία εφαρμογή, της οποίας το κλειδί (key) του process definition υπάρχει ήδη στον πίνακα. ii) Πίνακας ACT_ID_USER Περιέχει όλους τους χρήστες που έχουν δημιουργηθεί κι έχουν πρόσβαση στην πλατφόρμα Camunda. Χαρακτηρίζονται μοναδικά από το id (που, ουσιαστικά, είναι το username) και τα υπόλοιπα πεδία είναι το όνομα (first), το επώνυμο (last), η ηλεκτρονική διεύθυνση ( ) και ο κωδικός πρόσβασης (pwd). Ο κωδικός αποθηκεύεται σε μορφή SHA1. Να σημειωθεί ότι ο ρόλος του χρήστη και το group, στο οποίο ανήκει, δεν προσδιορίζονται σε αυτόν τον πίνακα, αλλά στους πίνακες act_id_membership και act_id_group αντίστοιχα, με τους οποίους υπάρχει σύνδεση (όπως φαίνεται και στο σχεδιάγραμμα της βάσης). 27

29 Εικόνα 3.4: Τα πεδία του πίνακα ACT_ID_ USER iii) Πίνακας ACT_HI_PROCINST Περιέχει όλα τα στιγμιότυπα των διαδικασιών, που έχουν ξεκινήσει, είτε αυτά έχουν ολοκληρωθεί είτε βρίσκονται σε εξέλιξη. Χαρακτηρίζονται από ένα μοναδικό id, ενώ ενημερωνόμαστε, επίσης, σε ποιο process definition ανήκει το συγκεκριμένο instance (proc_def_id_), την ημερομηνία/ώρα έναρξης (start_time) και την ημερομηνία λήξης (αν αυτό έχει ολοκληρωθεί), τη διάρκειά του (duration), καθώς και για το ποιος χρήστης ξεκίνησε το στιγμιότυπο (start_user). Εικόνα 3.5: Τα πεδία του πίνακα ACT_HI_ PROCINST iv) Πίνακας ACT_RU_TASK Αναφέρεται στα εκκρεμή User Task, των στιγμιοτύπων που βρίσκονται σε εξέλιξη. Όπως και στους προηγούμενος πίνακες, έτσι κι εδώ κάθε εγγραφή προσδιορίζεται από ένα μοναδικό id. Οι σημαντικότερες πληροφορίες που λαμβάνουμε είναι το id του process definition και του process instance, από το οποίο προέρχεται το task, το όνομα του Task 28

30 (name), τον χρήστη στον οποίον έχει ανατεθεί η εκπλήρωσή του (assignee), την ημερομηνία δημιουργίας του (create_time) και την προθεσμία ολοκλήρωσής του (due_date). Εικόνα 3.6: Ta πεδία του πίνακα ACT_RU_ TASK v) Πίνακας ACT_RU_VARIABLE Περιέχει τις τιμές όλων των μεταβλητών των διαφορών tasks ή στιγμιοτύπων, που εκκρεμούν. Παράδειγμα τέτοιων αποτελούν οι τιμές που συμπληρώνονται από έναν χρήστη σε μια φόρμα. Χαρακτηρίζονται από ένα μοναδικό ID, το id του process instance (proc_inst_id) και του task (task_id), στο οποίο ανήκει, τον τύπο της μεταβλητής (type) και την τιμή της μεταβλητής σε κάποια από τις στήλες double, long, text (ανάλογα με τον τύπο της). vi) Πίνακε ACT_HI_TASKINST και ACT_HI_VARINST Οι συγκεκριμένοι πίνακες παρέχουν τα αντίστοιχα στοιχεία με τους πίνακες ACT_RU_TASKS και ACT_HI_VARIABLE, με τη διαφορά ότι καθένας από αυτούς περιέχει στοιχεία που αφορούν και τα process instances που έχουν ολοκληρωθεί. 29

31 3.3 Εγκατάσταση πλατφόρμας Camunda ΒPM Όπως φαίνεται και στην εικόνα 3.1, εντός του Apache Tomcat εγκαταστάθηκε η πλατφόρμα BPM Camunda. Αρκεί η αντιγραφή του αρχείου «camunda-webapp-tomcat-standalone war» (το οποίο ελήφθη από την τοποθεσία στο φάκελο webapps του $TOMCAT_HOME, το οποίο θα μετατραπεί σε φάκελο με όνομα «camunda-webapp-tomcat-standalone-7.2.0», μετά την έναρξη λειτουργίας του Tomcat. Για λόγους ευκολίας, μετονομάζουμε το αρχείο σε «camunda-new». Πλέον έχουμε πρόσβαση στις εφαρμογές του Camunda στις εξής διευθύνσεις: - για την εφαρμογή Tasklist - για την εφαρμογή Cockpit - για την εφαρμογή Admin Για την πραγματοποίηση των REST ερωτημάτων, χρειάζεται να γίνει deploy μιας επιπλέον εφαρμογή, της οποίας η λήψη έγινε από τον ιστότοπο: Εφόσον δεν προκύψει κάποιο σφάλμα, τα REST ερωτήματα προς την process engine θα γίνονται μέσω της διεύθυνσης: Μοντελοποίηση διαδικασίας-λειτουργικές απαιτήσεις Η μοντελοποίηση μιας διαδικασίας πραγματοποιείται με το πρόγραμμα Camunda Modeller. Στο παρελθόν, αποτελούσε ένα ανοιχτού κώδικα plug-in για το Eclipse, αλλά πλέον παρέχεται ως ξεχωριστή εφαρμογή από τον ιστότοπο του Camunda. Υποστηρίζει πλήρως το πρότυπο BPMN 2.0 κι εστιάζει στη μοντελοποίηση επιχειρηματικών διαδικασιών. Τα διαγράμματα μπορούν να γίνουν κατανοητά τόσο από επιχειρηματικούς αναλυτές όσο κι από προγραμματιστές. Στην περίπτωσή μας, επιθυμούμε να μοντελοποιηθεί η διαδικασία αίτησης αδείας από ένα μέλος ΔΕΠ. Οι ρόλοι που εμπλέκονται είναι οι εξής: 30

32 1. Μέλος ΔΕΠ, το οποίο διαθέτει κατάλληλα στοιχεία εισόδου στην πλατφόρμα του Camunda 2. Υπάλληλος του τμήματος πρωτοκόλλου, με κατάλληλα στοιχεία εισόδου στην πλατφόρμα Camunda 3. Υπάλληλος του τμήματος προσωπικού, ο οποίος διαθέτει κατάλληλα στοιχεία εισόδου στην πλατφόρμα του Camunda Μέσω της εφαρμογής Admin, δημιουργούμε τρεις ομάδες χρηστών (Groups), όπου καθεμία θα αντιπροσωπεύει τους τρεις παραπάνω ρόλους. Τα groups αυτά ονομάστηκαν DEP (για τα μέλη ΔΕΠ), Protokollo (για τους υπαλλήλους του τμήματος Πρωτοκόλλου) και Prosopiko (για το τμήμα Προσωπικού). Οι ενέργειες που επιθυμούμε να μοντελοποιηθούν είναι οι εξής: 1. Το μέλος ΔΕΠ, αφού εισέλθει στην πλατφόρμα, πρέπει να μπορεί να συμπληρώσει μία φόρμα με τα στοιχεία του και την επιθυμητή ημερομηνία αδείας (Όνομα, Επίθετο, Κωδικός Ασφαλείας, Βαθμίδα, Τμήμα στο οποίο ανήκει, Ημερομηνία Έναρξης Αδείας, Ημερομηνία Λήξης Αδείας και το του). Με την ολοκλήρωση της συμπλήρωσής της, δημιουργείται στιγμιότυπο (process instance) της διαδικασίας. 2. Ο υπάλληλος του τμήματος πρωτοκόλλου και του τμήματος προσωπικού πρέπει να λάβει , με το οποίο να ειδοποιείται ότι υπάρχει νέο αίτημα, στο οποίο πρέπει να ανταποκριθεί. 3. Ο υπάλληλος πρωτοκόλλου, αφού εισέλθει στην πλατφόρμα του Camunda, πρέπει να μπορεί να δει το νέο αίτημα στο Camunda Tasklist. 4. Ο υπάλληλος πρωτοκόλλου πρέπει να μπορεί να εισάγει αριθμό Πρωτοκόλλου στο αίτημα και ακολούθως, να το υποβάλλει. 5. Ο υπάλληλος προσωπικού, αφού εισέλθει στην πλατφόρμα του Camunda, πρέπει να μπορεί να δει το νέο αίτημα στο Camunda Tasklist. 6. Ο υπάλληλος προσωπικού πρέπει να μπορεί να εγκρίνει ή να απορρίψει το αίτημα. 7. Αν ο υπάλληλος προσωπικού απορρίψει το αίτημα, πρέπει αυτόματα να στέλνεται e- mail στην ηλεκτρονική διεύθυνση που έδωσε το μέλος ΔΕΠ κατά τη συμπλήρωση της φόρμας, στο οποίο να αναφέρεται ότι το αίτημα του απορρίφθηκε από το τμήμα προσωπικού του Πανεπιστημίου Μακεδονίας. 31

33 8. Αν ο υπάλληλος προσωπικού εγκρίνει το αίτημα, πρέπει αυτόματα να στέλνεται e- mail που έδωσε το μέλος ΔΕΠ κατά τη συμπλήρωση της φόρμας, στο οποίο να αναφέρεται ότι το αίτημα του εγκρίθηκε από το τμήμα προσωπικού του πανεπιστημίου Μακεδονίας και να επιβεβαιώνει τις ημέρες έναρξης και λήξης της άδειας. Το BPMN διάγραμμα που δημιουργήθηκε κι απεικονίζει τις παραπάνω ενέργειες είναι το εξής: Εικόνα 3.7: Μοντελοποίηση της διαδικασίας "Αίτημα αδείας από μέλος ΔΕΠ" σε BPMN διάγραμμα Αποθηκεύτηκε σε αρχείο τύπου.bpmn, στο οποίο εκτός από το διάγραμμα, περιλαμβάνεται και η περιγραφή του σε μορφή XML, η οποία φαίνεται στο παράρτημα. Το διάγραμμα αποτελείται από τους εξής τύπους στοιχείων: 1. Pool: Θεωρείται ως τέτοιο το σύνολο του σχήματος κι αντιπροσωπεύει μια γενική οντότητα, που, στην περίπτωσή μας, είναι το πανεπιστήμιο. Χρησιμοποιείται για να ορίσει τα όρια, στα οποία επεκτείνεται μια διαδικασία. 2. Lanes: Καθένα από τα τρία ορθογώνια που βρίσκονται στο Pool και που χωρίζονται από τη μεσαία γραμμή αποτελούν ένα Lane κι έχουν ονομασίες «Μέλος ΔΕΠ», 32

34 «Τμήμα Πρωτοκόλλου» και «Τμήμα Προσωπικού». Χρησιμεύουν στον ορισμό ρόλων και των δραστηριοτήτων που αντιστοιχούν σε καθέναν από αυτούς. 3. Start Event: Είναι το σημείο, από το οποίο ξεκινάει η διαδικασία. Μέσα από τον Camunda Modeller, ορίστηκε μία φόρμα, της οποίας η συμπλήρωση αποτελεί το έναυσμα για την έναρξη ενός νέου στιγμιοτύπου του process. Ανήκει στο Lane «Μέλος ΔΕΠ», που σημαίνει ότι η συμπλήρωση πρέπει να πραγματοποιηθεί από κάποιο άτομο με το συγκεκριμένο ρόλο. Η φόρμα αποτελείται από τα εξής πεδία: i. Όνομα ii. Επώνυμο iii. Κωδικός ασφαλείας. Αποτελεί έναν σύνολο χαρακτήρων, ο οποίος παρέχεται εμπιστευτικά σε κάθε μέλος ΔΕΠ, έτσι ώστε να εξασφαλιστεί ότι δε θα πραγματοποιηθεί αίτηση άδειας από κάποιον χρήστη για λογαριασμό άλλου. iv. Βαθμίδα, όπου ο χρήστης επιλέγει από ένα dropdown menu μεταξύ των επιλογών: Επίκουρος Καθηγητής, Αναπληρωτής Καθηγητής, Καθηγητής v. Τμήμα, όπου ο χρήστης επιλέγει από ένα dropdown menu μεταξύ των επιλογών: Εφαρμοσμένης Πληροφορικής, Λογιστικής & Χρηματοοοικονομικής vi. Ημερομηνία έναρξης, όπου ο χρήστης μπορεί να πληκτρολογήσει την επιθυμητή ημερομηνία έναρξης άδειας ή να την επιλέξει από ένα ημερολόγιο. vii. Ημερομηνία λήξης, όπου ο χρήστης μπορεί να πληκτρολογήσει την επιθυμητή ημερομηνία λήξης άδειας ή να την επιλέξει από ένα ημερολόγιο. viii. , που αποτελεί το με το οποίο θα ενημερωθεί για την πορεία του αιτήματός του με αυτοματοποιημένο μήνυμα από το τμήμα Προσωπικού Όλα τα παραπάνω στοιχεία πρέπει να συμπληρωθούν υποχρεωτικά, ώστε να ολοκληρωθεί η καταχώριση της φόρμας

35 Ακολουθεί η πρωτοκόλληση της αίτησης από το τμήμα Πρωτοκόλλου. Στην περίπτωση, αυτή χρησιμοποιείται το συγκεκριμένο σχήμα που ονομάζεται User Task (μεταφράζεται ως «Εργασία Χρήστη»), καθώς απαιτείται η ενέργεια κάποιου χρήστη με τη βοήθεια κάποιου λογισμικού για την ολοκλήρωση μιας εργασίας. Στις ιδιότητες του Task, ορίστηκε η ανάθεσή του σ έναν υπάλληλο του τμήματος Πρωτοκόλλου με συγκεκριμένο username (μέσω της ιδιότητας assignee ), όπως επίσης και η κλήση μιας Java κλάσης. Λειτουργία της κλάσης αυτής είναι η αποστολή στον υπάλληλο του τμήματος πρωτοκόλλου, το οποίο τον ενημερώνει ότι του έχει ανατεθεί ένα νέο Task. To αντλείται από το προφίλ του χρήστη, όπως αυτό έχει δηλωθεί κατά τη δημιουργία χρηστών στην πλατφόρμα Camunda. Όταν ο υπάλληλος εισάγει τον αριθμό πρωτοκόλλου στο ανάλογο πεδίο, ολοκληρώνεται το User Task. 4. Ακολουθεί ο έλεγχος της αίτησης από το τμήμα Προσωπικού. Όπως παραπάνω, στις ιδιότητες του Task, ορίστηκε η ανάθεσή του σ έναν υπάλληλο του τμήματος Προσωπικού με συγκεκριμένο username όπως επίσης και η κλήση μιας Java κλάσης, η οποία έχει παρόμοια λειτουργικότητα με αυτήν που καλείται από το User Task Πρωτοκόλληση Αίτησης, δηλαδή ενημερώνει τον υπάλληλο του τμήματος Προσωπικού ότι πρέπει ν αποκριθεί σ ένα νέο αίτημα. Όταν ο χρήστης του τμήματος Προσωπικού επιλέξει να εγκρίνει ή να απορρίψει το αίτημα, ολοκληρώνεται το User Task. 5. Στη συνέχεια, χρησιμοποιείται ένας άλλος τύπος Task, που ονομάζεται Script Task και διαφοροποιείται από το User Task με το ειδικό σύμβολο που φαίνεται στην εικόνα. Σκοπός 34

36 του είναι να δείξει ότι πρέπει να εκτελεστεί ένα Script από την process engine, το οποίο είναι γραμμένο σε γλώσσα κατανοητή από αυτήν. Στην περίπτωσή μας, στόχος του Script Task ήταν η μετατροπή των στοιχείων της φόρμας, καθώς και της έγκρισης ή απόρριψης σε μεταβλητές, οι οποίες θα μπορούν να χρησιμοποιηθούν σε Java κλάσεις. Έτσι, με το παρακάτω κομμάτι κώδικα σε γλώσσα AngularJS οι τιμές που συμπλήρωσε το μέλος ΔΕΠ και η απόφαση του τμήματος Προσωπικού αναθέτονται σε μεταβλητές: <script cam-script type="text/form-script"> camform.on('form-loaded', function() { camform.variablemanager.fetchvariable('approved'); camform.variablemanager.fetchvariable('firstname'); camform.variablemanager.fetchvariable(' '); camform.variablemanager.fetchvariable('startdate'); camform.variablemanager.fetchvariable('enddate'); }); </script> 6. Η απόφαση του τμήματος προσωπικού έχει πλέον μετατραπεί σε μία μεταβλητή κατανοητή από την process engine και είναι η μεταβλητή «approved». O διαχωρισμός των ενεργειών που πρέπει αν γίνουν ανάλογα με την τιμή της μεταβλητής γίνεται με τη χρήση ενός Gateway. 7. α)αν το αίτημα εγκρίθηκε (η μεταβλητή «approved» έχει τιμή «true»), εκτελείται ένα Service Task. Στη BPMN, αυτός ο τύπος task χρησιμεύει, όταν πρέπει να χρησιμοποιηθεί κάποιο service ή κάποια αυτοματοποιημένη εφαρμογή. Στην περίπτωση μας, η υλοποίηση πραγματοποιείται μέσω μιας κλάσης Java, η οποία λαμβάνει τις μεταβλητές που δημιουργήθηκαν από το script tasks και τις χρησιμοποιεί, έτσι ώστε να στείλει 35

37 έγκρισης στο μέλος ΔΕΠ, που πραγματοποίησε την αίτηση. Ως διεύθυνση αποστολής θεωρείται το , το οποίο εισήγαγε ο αιτών κατά τη συμπλήρωση της φόρμας. β) Αν το αίτημα δεν εγκρίθηκε (η μεταβλητή «approved» έχει τιμή «false»), εκτελείται ένα διαφορετικό Service task, το οποίο συνδέεται με την ίδια Java κλάση, αλλά εκτελείται ένα διαφορετικό κομμάτι της, σύμφωνα με το οποίο στέλνεται μήνυμα στο μέλος ΔΕΠ, στο οποίο αναφέρεται ότι το αίτημά του απορρίφθηκε και τον προτρέπει να επικοινωνήσει με το τμήμα προσωπικού του Πανεπιστημίου. 3.5 Δημιουργία εφαρμογής Η δημιουργία της εφαρμογής πραγματοποιείται μέσω της εφαρμογής Eclipse. Εκεί είναι απαραίτητο να εγκατασταθεί αρχικά το plugin m2e, το οποίο θα μας επιτρέπει να δημιουργήσουμε νέα Maven Project. Tο Maven αποτελεί ένα εργαλείο που χρησιμοποιείται για τη δημιουργία και διαχείριση οποιουδήποτε project, που βασίζεται στη Java. Αποτελεί ένα βολικό τρόπο δημιουργίας project, καθώς μέσω κάποιων αρχέτυπων, παρέχουν ένα βασικό σκελετό έναρξης αυτού. Οι εμπνευστές του Camunda έχουν δημιουργήσει τέτοια αρχέτυπα κι ενθαρρύνουν τους χρήστες του να τα χρησιμοποιούν κατά την έναρξη ενός project. Η διαδικασία ξεκινάει λοιπόν με τη δημιουργία ενός Maven Project, το οποίο βασίζεται στο αρχέτυπο με artifact id camunda-archetype-servlet-war, έκδοσης Επιλέγεται αυτό, καθώς αποτελεί το καταλληλότερο σε περίπτωση που επιθυμούμε την εισαγωγή της εφαρμογής σε Servlet Container (κι όχι σε Java EE Container), όπως είναι ο Apache Tomcat. Το project πλέον είναι ορατό στον «Package Explorer» του Eclipse, έχοντας την κατάλληλη δομή. Στο φάκελο src/main/java, υπάρχουν ήδη δύο κλάσεις και είναι οι εξής: - CamundaBpmProcessApplication.java: Αποτελεί μια συνηθισμένη κλάση Java και είναι η βάση για την ανάπτυξη Process Applications. Συνιστά τη διεπαφή μεταξύ της process engine και της εφαρμογής μας, καθώς κάνει αναζήτηση αυτής στον Container (τον Apache Tomcat). Δε κρίθηκε απαραίτητη η προσθήκη επιπλέον κώδικα σε αυτή την κλάση. 36

38 - LoggerDelegate.java: Κλάση που μόνο σκοπό έχει την επίδειξη χρήσης μιας Java κλάσης ως Service Task. Στον φάκελο src/main/java, δημιουργούμε κάποιες επιπλέον κλάσεις, όπως: - Assignment.java: Η κλάση αυτή καλείται από τα User Tasks «Πρωτοκόλληση Αίτησης» κι «Έλεγχος Αίτησης» και σε αυτήν έχει οριστεί η σύνδεση μ έναν Mail Server, από τον οποίο στέλνεται ένα ηλεκτρονικό μήνυμα στη διεύθυνση του χρήστη-υπαλλήλου, όταν δημιουργείται ένα νέο αίτημα, στο οποίο πρέπει να απαντήσει. - Notify.java: Είναι η κλάση που καλείται από τα Service Task Αποστολή έγκρισης και «Αποστολή απόρριψης», όταν ο χρήστης-υπάλληλος απαντήσει θετικά ή αρνητικά σ ένα αίτημα αντίστοιχα. Μέσα σε αυτή την κλάση, λαμβάνονται σε μεταβλητές οι τιμές της φόρμας που συμπλήρωσε το μέλος-δεπ και αξιοποιούνται, έτσι ώστε να σταλθεί ενημέρωσης προς το μέλος ΔΕΠ. Κι εδώ, ορίζονται οι ρυθμίσεις σύνδεσης μ έναν Mail Server για να είναι δυνατή η αποστολή των μηνυμάτων. Στο project, πρέπει να εισαχθεί και το αρχείο.bpmn, που ορίζει τη διαδικασία και συγκεκριμένα στο φάκελο src/main/resources. Μετά την ολοκλήρωση των παραπάνω, κάνοντας δεξί κλικ στο φάκελο project κι επιλέγοντας: Run As.-> Maven Install δημιουργείται ένα αρχείο war στο φάκελο target, που αποτελεί και την εφαρμογή. Αυτό το αρχείο πρέπει ν αντιγραφεί και να επικολληθεί στο φάκελο webapps του $TOMCAT_HOME. Αν δεν υπάρξει κάποιο σφάλμα, μπορεί πλέον να πραγματοποιηθεί νέο αίτημα αδείας μέσω της διεύθυνσης: Υλοποίηση REST διεπαφής Επεξήγηση τμημάτων κώδικα Όπως προαναφέρθηκε, δε διαθέτουμε δικαιώματα παρέμβασης στην επίσημη πλατφόρμα του Compus ( του Πανεπιστημίου Μακεδονίας, γι αυτό και κατασκευάστηκε μία ανάλογη ιστοσελίδα, στην οποία θεωρούμε ότι συνδέονται καθημερινά τόσο τα μέλη ΔΕΠ, όσο και τα μέλη του τμήματος Προσωπικού και Πρωτοκόλλου για τη 37

39 διεκπεραίωση διάφορων εργασιών. Η ιστοσελίδα αυτή δημιουργήθηκε στο Wordpress κι ονομάστηκε «Compus». Το Wordpress είναι ελεύθερο κι ανοικτού κώδικα λογισμικό ιστολογίου και πλατφόρμα δημοσιεύσεων, γραμμένο σε PHP και MySQL. Απαιτήθηκε η εγκατάσταση του σ έναν WAMP Server, o οποίος είναι μία στοίβα λογισμικού για Microsoft Windows, που αποτελείται από έναν Apache Web Server, βάση δεδομένων MySQL και τη γλώσσα προγραμματισμού PHP. Προηγήθηκε η δημιουργία βάσης, μέσω της εφαρμογής phpmyadmin, για την αποκλειστική χρήσης από το Wordpress. Κατά τη διάρκεια εγκατάστασης του Wordpress, ορίστηκε η σύνδεση με τη βάση δεδομένων που υλοποιήθηκε. Έχοντας στήσει κατάλληλα το Wordpress στον WAMP Server, μπορούμε πλέον να συνδεθούμε σε αυτό. Αρχικά πρέπει να εγκατασταθεί το plugin PHP Code for Posts, έτσι ώστε να υπάρχει η δυνατότητα εισαγωγής και μεταγλώττισης κώδικα PHP. Παρακάτω, θ αναλυθεί ο κώδικας της εφαρμογής Script «Check User» Αρχικά, πρέπει να δημιουργηθούν τόσοι χρήστες όσοι δημιουργήθηκαν στην πλατφόρμα BPM, φροντίζοντας να έχουν τα ίδια username. Για τον ελέγχο του ρόλου του χρήστη, δηλαδή αν είναι μέλος ΔΕΠ ή υπάλληλος ενός εκ των τμημάτων Προσωπικού ή Πρωτοκόλλου, δημιουργήθηκε το Script Check User, εντός του οποίου: 1) Λαμβάνεται το username του συνδεδεμένου χρήστη στη γραμμή 2 και ανατίθεται στη μεταβλητή $cur (γραμμή 3). 2) Στις γραμμές 4-13, πραγματοποιείται REST ερώτημα (GET) προς τη διεύθυνση όπου $cur είναι το username του συνδεδεμένου χρήστη. 3) Στις γραμμές 14-20, ανατίθεται στη μεταβλητή $result η απάντηση από το REST ερώτημα, η οποία είναι σε μορφή JSON. Ένα παράδειγμα απόκρισης που μπορεί να ληφθεί είναι το εξής: { "groups": [ { "id": "camunda-admin", "name": "camunda BPM Administrators" 38

40 } ], "groupusers": [] } To group του χρήστη περιέχεται στην ιδιότητα id του JSON πίνακα groups. Γίνεται η αποκωδικοποίησή του $result με τη διαδικασία json_decode σε PHP object (μεταβλήτή $groups), έτσι ώστε να μπορέσει να επεξεργαστεί κατάλληλα. Εντός του βρόχου foreach, ανατίθεται η τιμή του «id» στη μεταβλητή $val, η οποία αποτελεί PHP πίνακα. Στις γραμμές 21-39, ελέγχεται η ομάδα χρηστών στην οποία ανήκει ο χρήστης μέσω της πρώτης τιμής του πίνακα $val (καθώς κάθε χρήστης ανήκει σε μία μόνο ομάδα χρηστών). Ανάλογα με το group του, ο χρήστης έχει πρόσβαση σε διαφορετικά resources κι έχει διαφορετικά δικαιώματα. Για παράδειγμα, ένα μέλος ΔΕΠ δεν θα χει το δικαίωμα να δει τα αιτήματα αδειών των υπόλοιπων μελών ΔΕΠ. Ακολούθως, δημιουργούμε ένα Post, στο οποίο θα περιέχεται η φόρμα που πρέπει να συμπληρώσει το μέλος ΔΕΠ Ανάλυση του xml της διαδικασίας Πριν προχωρήσουμε στην ανάλυση του τρόπου με τον οποίο υλοποιήθηκε ο REST Client, πρέπει να περιγραφούν κάποια σημεία του xml που προέκυψε από τη μοντελοποίησης της διαδικασίας «Αίτημα αδείας»,. O ορισμός της διαδικασίας ξεκινάει από τη γραμμή 1 και τελειώνει στη γραμμή 220, ενώ οι γραμμές αφορούν το πως αναπαριστάται σε διάγραμμα. Στις γραμμές , δηλώνεται ότι η έναρξη του στιγμιοτύπου της διαδικασίας γίνεται με τη συμπλήρωση της φόρμας. Η φόρμα περιέχεται εντός του tag «camunda:formdata» και καθένα από τα tags «camunda: formfield» αποτελεί πεδίο της φόρμας. Η ετικέτα του πεδίου εμφανίζεται στο attribute «label» κι ο τύπος του πεδίου στο attribute «type». Τα πεδία που είναι υποχρεωτικό να συμπληρωθούν διαθέτουν εμφωλευμένα το tag «camunda: constraint» με name «required». Οι γραμμές αναφέρονται στο user Task που πρέπει να ολοκληρώσει ο υπάλληλος του τμήματος Πρωτοκόλλου. Η ανάθεση στο συγκεκριμένο χρήστη γίνεται μέσω της ιδιότητας «camunda:assignee». Πρέπει να συμπληρώσει μια φόρμα, η οποία περιέχεται 39

41 εντός του tag «camunda:formdata». Σε αυτήν, εμφανίζονται τα πεδία που συμπλήρωσε το μέλος ΔΕΠ, στα οποία δεν έχει δικαίωμα να παρέμβει (αυτό ορίζεται μέσω του εμφωλευμένου tag «camunda:constraint» με name «readonly») και το πεδίο με label «Αριθμός Πρωτοκόλλου», που πρέπει υποχρεωτικά να συμπληρώσει (ορίζεται μέσω του εμφωλευμένου tag «camunda:constraint» με name «required»). Οι γραμμές αναφέρονται στο user task που πρέπει να ολοκληρώσει ο υπάλληλος του τμήματος Προσωπικού. Έχει παρόμοια σύνταξη με το user task του υπαλλήλου Πρωτοκόλλου, με τη διαφορά ότι αλλάζει ο χρήστης ανάθεσης (ιδιότητα «camunda:assignee»), το πεδίο με label «Αριθμός Πρωτοκόλλου» είναι μόνο προς ανάγνωση και πρέπει να συμπληρώσει ένα επιπλέον πεδίο, το πεδίο με label «Έγκριση» Script «Start Instance» Το συγκεκριμένο Script εκτελείται, όταν ο χρήστης «Μέλος ΔΕΠ» εισέλθει στην ανάρτηση με τίτλο «Αίτημα Αδείας» (σύνδεσμος Σκοπός είναι η εμφάνιση της φόρμας αδείας και η επιτυχής υποβολή της, μετά τη συμπλήρωσή της από το μέλος ΔΕΠ. Η δομή της φόρμας περιέχεται στο xml του bpmn αρχείου που δημιουργήθηκε κατά τη μοντελοποίηση της διαδικασίας. Οπότε, αρχικά πρέπει να λάβουμε το xml αρχείο από την process engine και στη συνέχεια, να το επεξεργαστούμε αναλόγως. Επομένως: 1. Στις γραμμές 14-25, πραγματοποιείται ένα GET ερώτημα προς τη διεύθυνση ' localhost:8081/engine-rest/process - definition / key / Process_1 /xml', όπου Process-1 είναι το key (κλειδί) της διαδικασίας που δημιουργήσαμε. 2. Στη γραμμή 26, στη μεταβλητή $result λαμβάνεται η απόκριση του REST ερωτήματος, που είναι το αρχείο xml της διαδικασίας σε μορφή json, το οποίο μετατρέπεται σε PHP Object στη γραμμή 27, ώστε να γίνει η επεξεργασία του. 3. Επιθυμούμε την ανάλυση του xml αρχείου και συγκεκριμένα, τον εντοπισμό της φόρμας και των δομικών στοιχείων της. Για τον σκοπό αυτό χρησιμοποιείται η βιβλιοθήκη Simple HTML DOM Parser, την οποία τη συμπεριλαμβάνουμε στη γραμμή 13. ΤΟ DOM αποτελεί ένα πρότυπο για την πρόσβαση σε κώδικα XML και HTML. Στη γραμμή 32, με τη μέθοδο str_get_html δημιουργείται ένα DOM αντικείμενο, που περιέχει τον κώδικα xml της διαδικασίας. Στις γραμμές 34-67, σαρώνεται αυτό το αντικείμενο μέσω της μεθόδου find 40

42 για tags, τα στοιχεία των οποίων θα μετατραπούν αναλόγως σε ετικέτες, πεδία εισαγωγής, και κουμπιά σε μορφή HTML. Συγκεκριμένα: Στη γραμμή 34, εντοπίζεται το σημείο από το οποίο ξεκινά ο ορισμός της διαδικασίας και είναι το tag «bpmn: StartEvent». Εφόσον εντός αυτού βρεθεί tag με το αναγνωριστικό «camunda: form data», σημαίνει ότι περιέχεται μια φόρμα. Εντός αυτής, όταν εντοπιστεί tag με το αναγνωριστικό «camunda:formfield», σημαίνει ότι έχουμε ένα νέο πεδίο φόρμας. Η ετικέτα του πεδίου της φόρμας που θα δημιουργηθεί ορίζεται από την τιμή του attribute «label» (γραμμή 42), ενώ η τιμή του attribute «type» θα είναι ο τύπος εισαγωγής του πεδίου. Aν το attribute «type» έχει την τιμή: -«string», σημαίνει ότι πρόκειται για πεδίο εισαγωγής κειμένου. -«enum», πρόκεται για πεδίο με συγκεκριμένες δυνατότητες επιλογής. Οι επιλογές αυτές εξάγονται μέσω του tag camunda:value. -«date», είναι πεδίο επιλογής ημερομηνίας. -«long», ο χρήστης θα μπορεί να εισάγει μόνο αριθμούς σε αυτό το πεδίο. Για καθένα από τα παραπάνω πεδία, εξάγονται και οι περιορισμοί (tag «camunda:validation»). Έτσι, αν βρεθεί κάποιο tag «camunda:validation», γίνεται αναζήτηση εντός αυτού για τα tags «camunda:constraint», τα οποία αν περιέχουν attribute «name» με τιμή «required», σημαίνει ότι αυτό το πεδίο πρέπει να οριστεί ως υποχρεωτικό. Αφού έχουν εκτυπωθεί στην οθόνη όλα τα πεδία της φόρμας, γίνεται εμφάνιση και του κουμπιού «Υποβολή» (γραμμή 66). 4. Στις γραμμές , είναι ο κώδικας για την αποστολή της φόρμας, όταν ο χρήστηςμέλος ΔΕΠ συμπληρώσει τη φόρμα και πατήσει «υποβολή». Δημιουργείται REST ερώτημα με τη μέθοδο POST προς τη διεύθυνση: όπου «Process_1» είναι το κλειδί της διαδικασίας. 41

43 Στις γραμμές 73-84, γίνεται σύνθεση του σώματος (body) του REST ερωτήματος. Σε αυτό περιέχονται τα ονόματα των ετικετών των πεδίων και οι τιμές που έδωσε ο χρήστης. Παράδειγμα, αν ο χρήστης συμπληρώσει τη φόρμα ως εξής: το σώμα του REST ερωτήματος θα διαμορφωθεί ως εξής: {"variables": { "EndDate": { "value": "30/12/2016" }, "StartDate": { "value": "29/12/2016" }, " ": { "value": "swtirist141@windowslive.com" }, "Tmima": { "value": "Log" }, "lastname": { "value": "Σωτήριος" }, "job": { "value": "Anaplirotis" }, 42

44 "firstname": { "value": "Τσακιρίδης" }, "code": { "value": "5677" } }} Script «Tasklist» Από την άλλη, για την παρουσίαση του tasklist του υπαλλήλου, δημιουργούμε μια νέα ανάρτηση στο wordpress με τίτλο «Εργασίες προς Ολοκλήρωση», στην οποία έχει πρόσβαση μόνο ο υπάλληλος. Προφανώς, τα δεδομένα διαφοροποιούνται μεταξύ των υπαλλήλων των δύο τμημάτων. Το Script Tasklist αρχίζει να εκτελείται όταν ο υπάλληλος εισέλθει στη συγκεκριμένη ανάρτηση. Τότε: 1. Στις γραμμές 6-7, λαμβάνεται το όνομα χρήστη που έχει συνδεθεί κι αποθηκεύεται στη μεταβλητή $cur. 2. Επιθυμούμε να επιστραφούν όλες οι εργασίες που έχουν ανατεθεί στο συγκεκριμένο υπάλληλο. Στις γραμμές 9-18, πραγματοποιείται REST ερώτημα με τη μέθοδο GET προς τη διεύθυνση: (όπου $cur είναι το user name του συνδεδεμένου χρήστη) 3. Στη γραμμή 19, επιστρέφεται σε μορφή JSON στη μεταβλητή $result το σύνολο των αιτημάτων προς απάντηση, που έχουν ανατεθεί στο συγκεκριμένο συνδεδεμένο χρήστηυπάλληλο. Αν η μεταβλητή $result έχει κενό περιεχόμενο (γραμμή 20), σημαίνει ότι δεν έχουν ανατεθεί αιτήματα στο χρήστη κι εμφανίζεται το μήνυμα «No tasks to complete». Αν η μεταβλητή $result έχει περιεχόμενο, το JSON φροντίζουμε να μετατραπεί σε PHP object (με τη συνάρτηση json_decode), όπου καθένα από τα στοιχεία του αποτελεί task, στου οποίου τις ιδιότητες περιέχονται πληροφορίες όπως τ όνομα του, η ημερομηνία κι ώρα υποβολής του, το id του, το process instance στο οποίο ανήκει κλπ. Στις γραμμές 24-51, δημιουργείται πίνακας, όπου ο χρήστης βλέπει συνολικά τα tasks που του ανατέθηκαν και συγκεκριμένα, το όνομα του κάθε task, η ημερομηνία κι ώρα υποβολής κι ένα κουμπί με την ονομασία «Δείτε Λεπτομέρειες». 43

45 Εικόνα 3.8: Ο πίνακας εργασιών προς ολοκλήρωση 4. Ο κώδικας των γραμμών εκτελείται, όταν ο χρήστης πατήσει «Δείτε Λεπτομέρειες» σε κάποια από τις γραμμές του πίνακα. Σκοπός είναι η εμφάνιση των πληροφοριών που αφορούν το task και συγκεκριμένα, της φόρμας που συμπλήρωσε το μέλος ΔΕΠ. Έτσι, δημιουργείται ένα νέο REST ερώτημα με τη μέθοδο GET (γραμμές 54-67) προς τη διεύθυνση: όπου «id» έιναι το id του task. Ένα παράδειγμα του αποτελέσματος που μπορεί να λάβουμε (μεταβλητή $result) έχει την παρακάτω μορφή: {"approved":{"type":"boolean","value":null,"valueinfo":{}},"enddate":{"type":"string","value ":"30/11/2016","valueInfo":{}},"StartDate":{"type":"String","value":"24/11/2016","valueInfo ":{"type":"string","value":"efar","valueinfo":{}},"lastname":{"type":"string","value":"tsakiridi s","valueinfo":{}},"job":{"type":"string","value":"epikouros","valueinfo":{}},"firstname":{"typ e":"string","value":"sotiris","valueinfo":{}}} Όπως φαίνεται, με αυτό το ερώτημα δεν μπορούμε να εξάγουμε τις ετικέτες των πεδίων (δηλαδή τις ετικέτες «Όνομα», «Επώνυμο», «Ημερομηνία Έναρξης» κ.ο.κ.). Γι αυτό, στις γραμμές 81-90, λαμβάνουμε εκ νέου το xml της διαδικασίας με REST ερώτημα μεθόδου GET προς τη διεύθυνση: 44

46 Σε μορφή json θα ληφθεί το xml και θα χρησιμοποιηθεί η βιβλιοθήκη Simple_HTML_DOM_Parser για τη μετατροπή του σε DOM Object και την ανάλογη επεξεργασία του. Στις γραμμές , πραγματοποιείται η εκτύπωση των ετικετών των πεδίων, ενώ στις γραμμές εμφανίζονται οι τιμές που συμπλήρωσε το μέλος ΔΕΠ στο κάθε πεδίο. Στις γραμμές , εκτυπώνονται τα πεδία που πρέπει να συμπληρώσουν οι υπάλληλοι των τμημάτων και συγκεκριμένα, στα μέλη του τμήματος Πρωτοκόλλου εμφανίζεται το πεδίο «Αριθμός Πρωτοκόλλου», ενώ στα μέλη του τμήματος Προσωπικού εμφανίζεται και το πεδίο για την έγκριση ή απόρριψη της άδειας. Εικόνα 3.9: Η φόρμα, όπως εμφανίζεται στον υπάλληλο Πρωτοκόλλου Εικόνα 3.10: Η φόρμα, όπως εμφανίζεται στον υπάλληλο Προσωπικού 5. Στις γραμμές , όταν ο χρήστης-υπάλληλος πατήσει το κουμπί «Υποβολή», δημιουργείται ερώτημα τύπου POST προς τη διεύθυνση: όπου $id είναι το id του συγκεκριμένου task. Αυτό σημαίνει ότι δε δημιουργείται νέο task, αλλά μεταβάλλεται το υπάρχον. Όταν η υποβολή γίνεται από το χρήστη του τμήματος Πρωτοκόλλου, στο σώμα του ερωτήματος περιέχονται ο αριθμός πρωτοκόλλου που συμπλήρωσε και οι τιμές της φόρμας που συμπλήρωσε το μέλος ΔΕΠ, ενώ όταν υποβάλλεται από το χρήστη του τμήματος Προσωπικού, συμπεριλαμβάνεται και η μεταβλητή της απόφασής του. 45

47 3.7 Διαδικασία αίτησης αδείας απο μέλος ΔΕΠ μέσω της πλατφόρμας camunda Ι) Ενέργειες μέλους ΔΕΠ Θα εξετάσουμε βήμα βήμα τη διαδικασία αίτησης αδείας ενός μέλους ΔΕΠ με τις ενέργειες που πρέπει να κάνει και τα αποτελέσματα που θα προκύψουν. 1. Είσοδος στην πλατφόρμα Camunda BPM Αρχικά, ο χρήστης εισέρχεται στη διεύθυνση Πρέπει να εισάγει το όνομα χρήστη και τον κωδικό πρόσβασης, που του έχουν δοθεί από το διαχειριστή του συστήματος. ΠΡΟΣΟΧΗ: Ο χρήστης δεν έχει δικαίωμα πρόσβασης στην εφαρμογή Cockpit, οπότε πιθανή απόπειρα εισόδου στη διεύθυνση θα είναι αποτυχημένη. Εικόνα 3.11: Οθόνη εισόδου στην εφαρμογή Camunda Tasklist 2. Εφόσον τα στοιχεία του είναι σωστά, η επόμενη οθόνη που πρέπει να δει ο χρήστης είναι αυτή του Camunda Tasklist. Εικόνα 3.12: Η οθόνη του Camunda Tasklist 46

48 Όταν ο χρήστης πατήσει το κουμπί (Start Process Instance), θα εμφανιστεί μια λίστα με σύνολο των processes, που έχουν εισαχθεί στο Camunda. Ο χρήστης πρέπει να επιλέξει αυτό με την ονομασία «Αίτηση αδείας μέλους ΔΕΠ». 3. Τότε, ο χρήστης θα δει τη φόρμα που δημιουργήθηκε κατά το σχεδιασμό της διαδικασίας. Μετά την συμπλήρωση των στοιχείων, ο χρήστης πατάει το κουμπί Start, το οποίο πυροδοτεί την έναρξη ενός στιγμιοτύπου της διαδικασίας «Αίτησης αδείας μέλους ΔΕΠ». Εικόνα 3.13: Η φόρμα που πρέπει να συμπληρώσει το μέλος ΔΕΠ Εικόνα 3.14: Το μήνυμα που λαμβάνει ο υπάλληλος του τμήματος προσωπικού 47

49 Οι παραπάνω ενέργειες από πλευράς του χρήστη-μέλους ΔΕΠ, θα έχουν ως αποτέλεσμα να συμβούν δύο γεγονότα: 1) Στο Tasklist του χρήστη-υπαλλήλου του τμήματος πρωτοκόλλου, δημιουργείται νέο task, στο οποίο πρέπει ν ανταποκριθεί ο υπάλληλος, ώστε να προχωρήσει η διαδικασία παρακάτω. 2) Ο υπάλληλος του τμήματος πρωτοκόλλου θα λάβει ένα νέο (στην ηλεκτρονική διεύθυνση, που έχει οριστεί στο προφίλ του), στο οποίο θα ενημερώνεται πως πρέπει να απαντήσει σ ένα νέο αίτημα, παρέχοντας και τον σύνδεσμο του αιτήματος. II) Ενέργειες τμήματος Πρωτοκόλλου Ο χρήστης-υπάλληλος του τμήματος προσωπικού θα πρέπει να: 1) Πραγματοποιήσει είσοδο στην πλατφόρμα του camunda με τα διαπιστευτήριά του. 2) Στο Camunda Tasklist, στην αριστερή στήλη φαίνονται όλα τα task, στα οποία πρέπει ν ανταποκριθεί. Το πρώτο από αυτά δημιουργήθηκε από την παρούσα διαδικασία αίτησης του μέλους ΔΕΠ. Επιλέγοντας, λοιπόν αυτό, βλέπει σε πλήρη ανάπτυξη την φόρμα που συμπλήρωσε ο αιτών, χωρίς να έχει τη δυνατότητα να παρέμβει σε κάποιο από τα πεδία. Μπορεί μόνο να συμπληρώσει αριθμό Πρωτοκόλλου στο ομώνυμο πεδίο. Η απόφασή του καταχωρείται, κάνοντας κλικ στο κουμπί Complete, που θα σημάνει και τη συνέχιση της διαδικασίας. Ο υπάλληλος προσωπικού θα λάβει ένα παρόμοιο αυτοματοποιημένο μήνυμα με αυτό που έλαβε ο υπάλληλος πρωτοκόλλου (εικόνα 5), όταν του ανατέθηκε η απάντηση του αιτήματος. 48

50 Εικόνα 3.15: H φόρμα που εμφανίζεται στον υπάλληλο πρωτοκόλλου ΙII) Ενέργειες τμήματος Προσωπικού Ο χρήστης-υπάλληλος του τμήματος προσωπικού θα πρέπει να: 3) Πραγματοποιήσει είσοδο στην πλατφόρμα του camunda με τα διαπιστευτήριά του. 4) Στο Camunda Tasklist, στην αριστερή στήλη φαίνονται όλα τα task και το πρώτο από αυτά είναι το πιο πρόσφατο. Επιλέγοντας, λοιπόν αυτό, βλέπει σε πλήρη ανάπτυξη την φόρμα που συμπλήρωσε ο αιτών μαζί με τον αριθμό πρωτοκόλλου. Μπορεί μόνο να εγκρίνει το αίτημα, επιλέγοντας το πεδίο «Έγκριση» ή να το απορρίψει, αφήνοντας το συγκεκριμένο πεδίο κενό. Η απόφασή του καταχωρείται, κάνοντας κλικ στο κουμπί Complete, που θα σημάνει και τη συνέχιση της διαδικασίας. Από πλευράς του, ο υπάλληλος δε χρειάζεται να προβεί σε καμία περαιτέρω ενέργεια για την ενημέρωση του μέλους ΔΕΠ, καθώς θα σταλεί ένα αυτοματοποιημένο για την έκβαση του αιτήματός του. 49

51 Εικόνα 3.16: Το αίτημα, όπως το βλέπει στο Camunda Tasklist ο υπάλληλος του τμήματος Προσωπικου Εικόνα 3.17: To μήνυμα που λαμβάνει το μέλος ΔΕΠ, σε περίπτωση έγκρισης του αιτήματός του 3.8 Διαδικασία αίτησης αδείας μέλους ΔΕΠ μέσω του ιστοτόπου «Compus», χωρίς την ανάγκη εισόδου στην πλατφόρμα Camunda Όπως παρουσιάστηκε παραπάνω, ένα μέλος ΔΕΠ μπορεί να πραγματοποιήσει αίτηση για άδεια μέσω της πλατφόρμας Camunda, η οποία θα παραληφθεί από τον υπάλληλο πρωτοκόλλου για να πρωτοκολληθεί και στη συνέχεια, από τον υπεύθυνο υπάλληλο του τμήματος προσωπικού και θα εγκριθεί ή θ απορριφθεί αναλόγως. Μειονέκτημα, όμως, αποτελεί ότι τόσο ο χρήστης-μέλος ΔΕΠ όσο και ο χρήστης-υπάλληλος πρέπει να 50

52 πραγματοποιήσουν είσοδο σε μια ξεχωριστή πλατφόρμα (αυτή του Camunda) για την διεκπεραίωση των ενεργειών τους. Η αρχική σελίδα του ιστoτόπου που δημιουργήθηκε στο Wordpress φαίνεται παρακάτω: Εικόνα 3.18: Η αρχική σελίδα του Compus που δημιουργήθηκε Ενέργειες μέλους ΔΕΠ 1. Το μέλος ΔΕΠ πρέπει να εισέλθει στη σελίδα όπου στη δεξιά στήλη πρέπει να εισέλθει με τα στοιχεία εισόδου του. 2. Μετά από επιτυχή είσοδο, ο χρήστης θα αντικρύσει την παρακάτω οθόνη. Εικόνα 3.19: Η οθόνη που βλέπει το μέλος ΔΕΠ μετά τη σύνδεση Σε αυτή, αν κάνει κλικ στο «Αίτημα Αδείας», θα μπορέσει να δει τη φόρμα αδείας που πρέπει να συμπληρώσει. 51

53 Εικόνα 3.20: Η φόρμα, όμως εμφανίζεται στο Compus Μετά τη συμπλήρωση των στοιχείων και επιλέγοντας «Υποβολή», ολοκληρώνεται η διαδικασία αίτησης από το χρήστη-μέλος ΔΕΠ. Όπως και στην περίπτωση υποβολής αίτησης μέσω του περιβάλλοντος του Camunda, έτσι κι εδώ ο υπάλληλος του τμήματος πρωτοκόλλου θα λάβει , με το οποίο θα ενημερώνεται για το νέο task που του έχει ανατεθεί. Επίσης, θα προστίθεται το νέο task στη λίστα των εργασιών που πρέπει να ολοκληρώσει και η οποία θα παρουσιαστεί παρακάτω. Ενέργειες υπάλληλου τμήματος πρωτοκόλλου 1. Ο υπάλληλος πρέπει να εισέλθει στη σελίδα όπου στη δεξιά στήλη πρέπει να εισέλθει με τα στοιχεία εισόδου του. 2. Στην επόμενη οθόνη, αντικρίζει μια διαφορετική εικόνα από αυτή του μέλους ΔΕΠ. Βάσει δικαιωμάτων, έχει οριστεί ότι οι χρήστες που ανήκουν στο Group Employees, μπορούν να δουν και το post με τίτλο «Εργασίες προς Ολολήρωση». Σε αυτό, περιέχονται όλα τα Tasks που έχουν ανατεθεί στο χρήστη 52

54 και παίζει ουσιαστικά το ρόλο του Camunda Tasklist. Έτσι, ο υπάλληλος, αντί να πραγματοποιήσει είσοδο στην πλατφόρμα του Camunda, μπορεί να ανταποκριθεί στα διάφορα αιτήματα μέσα από το δικό του περιβάλλον. Εικόνα 3.21: Η αρχική σελίδα του Compus, όπως τη βλέπει ο υπάλληλος Ο χρήστης επιλέγει κάνοντας κλικ στην επιλογή «Εργασίες προς Ολοκλήρωση», μεταφέρεται στη λίστα των tasks που του έχουν ανατεθεί. Εικόνα 3.22: Τα tasks, που έχουν ανατεθεί στον υπάλληλο Μπορεί να πραγματοποιήσει ταξινόμηση σε όποια στήλη επιθυμεί και πατώντας στο κουμπί «Δείτε λεπτομέρειες», να εξετάσει τις παραμέτρους των αιτημάτων. Οι παράμετροι ενός αιτήματος και συγκεκριμένα, η φόρμα μαζί με το πεδίο που πρέπει να συμπληρώσει, παρουσιάζονται κάτω από τον πίνακα ως εξής: 53

55 Εικόνα 3.23: Η φόρμα, όπως εμφανίζεται στον υπάλληλο του τμήματος Προσωπικού Όπως φαίνεται και στην εικόνα, ενώ οι τιμές που έχει δώσει ο αιτών στο «Όνομα» και στο «Επώνυμο» έρχονται αυτούσιες, στις στήλες «Βαθμίδα» και «Τμήμα» εμφανίζονται τα id των βαθμίδων και των τμημάτων αντίστοιχα, χωρίς αυτό να δημιουργεί κάποιο πρόβλημα, καθώς ο υπάλληλος του τμήματος πρωτοκόλλου γνωρίζει σε ποιες οντότητες αντιστοιχούν αυτοί οι κωδικοί. Αφού εισάγει τον αριθμό πρωτοκόλλου και πατήσει «Υποβολή», η σελίδα θα ανανεωθεί αυτόματα και θα έχει αφαιρεθεί το συγκεκριμένο task από τη λίστα του υπαλλήλου. Ταυτόχρονα, ενημερώνεται μέσω ο υπάλληλος του τμήματος προσωπικού ότι πρέπει ν απαντήσει σ ένα νέο αίτημα. Ενέργειες υπάλληλου τμήματος προσωπικού 1. Ο υπάλληλος πρέπει να εισέλθει στη σελίδα όπου στη δεξιά στήλη πρέπει να εισέλθει με τα στοιχεία εισόδου του. 2. Στη συνέχεια, εμφανίζεται μια οθόνη, που έχει την ίδια όψη με αυτή του υπάλληλου πρωτοκόλλου. Επιλέγοντας «Εργασίες προς Ολοκλήρωση», μπορεί να δει τα αιτήματα στα οποία πρέπει ν απαντήσει. 54

56 Εικόνα 3.24: Η αρχική σελίδα του Compus, όπως τη βλέπει ο υπάλληλος Ο χρήστης επιλέγει κάνοντας κλικ στην επιλογή «Εργασίες προς Ολοκλήρωση», μεταφέρεται στη λίστα των tasks που του έχουν ανατεθεί. Εικόνα 3.25: Τα tasks, που έχουν ανατεθεί στον υπάλληλο Μπορεί να πραγματοποιήσει ταξινόμηση σε όποια στήλη επιθυμεί και πατώντας στο κουμπί «Δείτε λεπτομέρειες», να εξετάσει τις παραμέτρους των αιτημάτων. Οι παράμετροι ενός αιτήματος και συγκεκριμένα, η φόρμα μαζί με τις επιλογές Έγκρισης/Απόρριψης παρουσιάζονται κάτω από τον πίνακα ως εξής: 55

57 Εικόνα 3.26: Η φόρμα, όπως εμφανίζεται στον υπάλληλο του τμήματος Προσωπικού Όπως φαίνεται και στην εικόνα, ο υπάλληλος προσωπικού βλέπει τα στοιχεία της φόρμας που συμπλήρωσε το μέλος ΔΕΠ, όπως επίσης και τον αριθμό πρωτοκόλλου που συμπληρώθηκε από τον υπάλληλο πρωτοκόλλου. Αφού εξετάσει διάφορες παραμέτρους, μπορεί πλέον να απαντήσει στο αίτημα και να ενημερωθεί αυτοματοποιημένα το μέλος ΔΕΠ για την έκβαση του αιτήματός του. Μετά την υποβολή, η σελίδα θα ανανεωθεί αυτόματα και θα έχει αφαιρεθεί το συγκεκριμένο task από τη λίστα του υπαλλήλου. 56