Έχω το εξής να αντιμετωπίσω, το οποίο ίσως σας έχει προβληματίσει και εσάς κάποια στιγμή: Έστω ότι έχω ένα λογιστικό σύστημα το οποίο μεταξύ άλλων διατηρεί ένα πίνακα εργαζομένων για ευνόητους λόγους. Τα στοιχεία των εργαζομένων λαμβάνονται με μια διαδικασία import από ένα άλλο σύστημα. Αυτό το 2ο σύστημα για κάποιο λόγο έχει κάνει την παραδοχή ότι αν ο κωδικός του εργαζομένου (ID) ξεκινάει από 1 τότε αυτός είναι άντρας, ενώ αν ξεκινάει με 2 είναι γυναίκα. Επίσης έχει κάνει την παραδοχή ότι το δεύτερο ψηφίο δηλώνει αν είναι έλληνας υπήκοος ή αλλοδαπός και το τρίτο ψηφίο δηλώνει τον τρόπο ασφάλισης. Γιατί γίνεται αυτό; Δεν το εξετάζω γιατί πρόκειται για παλιό σύστημα το οποίο σχεδιάστηκε σε άλλες εποχές και περιόδους δύσκολες για το software - τουλάχιστον πιο δύσκολες από τις σημερινές.

Το ζητούμενο είναι ότι εφόσον η πληροφορία αυτή δίνεται στο ID, το σύστημα που λαμβάνει τα δεδομένα πρέπει να την αποκωδικοποιεί και να ενημερώνει τα αντίστοιχα πεδία στην βάση δεδομένων. Επίσης δεν πρέπει πλέον κανείς να μπορεί να αλλάξει αυτή την πληροφορία από την φόρμα επεξεργασίας του εργαζόμενου, εφόσον πρόκειται για πληροφορία που τηρείται σε άλλο σύστημα.

1) Γνώμη μου είναι ότι αυτή είναι μια αρκετά custom διαδικασία και ότι αν θέλω να μπορώ να εισάγω στο σύστημά μου εργαζόμενους και από άλλα συστήματα (π.χ. άλλου πελάτη) πρέπει η διαδικασία μου να μην περιορίζεται από αυτό το ID. Π.χ. ένα άλλο σύστημα μπορεί να εξάγει και αυτό τις ίδιες πληροφορίες αλλά σαν ξεχωριστά πεδία σε ένα delimited αρχείο και όχι κωδικοποιημένες σε ένα ID. Επίσης άλλο σύστημα μπορεί να μην τις εξάγει καθόλου και να πρέπει να τις δώσει ο τελικός χρήστης.

2) Η απαίτηση όμως ότι αν η πληροφορία έρχεται από άλλο σύστημα δεν πρέπει να μπορεί να τροποποιηθεί από το δικό μου είναι αρκετά λογική.

Γνώμες;

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Θα πρέπει να μπορούν να δουλεύουν και παράλληλα τα συστήματα; μάλλον ναι ε; τότε τι θα κάνεις θα τα συγχρονίζεις;

papadi wrote:

Γιατί γίνεται αυτό; Δεν το εξετάζω γιατί πρόκειται για παλιό σύστημα το οποίο σχεδιάστηκε σε άλλες εποχές και περιόδους δύσκολες για το software - τουλάχιστον πιο δύσκολες από τις σημερινές.

Είσαι παλικάρι, οι περισσότεροι και μάλλον κι εγώ δεν θα είμασταν τόσο ευγενείς.

papadi wrote:

Το ζητούμενο είναι ότι εφόσον η πληροφορία αυτή δίνεται στο ID, το σύστημα που λαμβάνει τα δεδομένα πρέπει να την αποκωδικοποιεί και να ενημερώνει τα αντίστοιχα πεδία στην βάση δεδομένων. Επίσης δεν πρέπει πλέον κανείς να μπορεί να αλλάξει αυτή την πληροφορία από την φόρμα επεξεργασίας του εργαζόμενου, εφόσον πρόκειται για πληροφορία που τηρείται σε άλλο σύστημα.

Και αν κάποιος θέλει να κάνει ενημέρωση τι πρέπει να κάνει; να πάει στο παλιό, να κάνει τις αλλαγές (αλλάζωντας το id???!!! ) και μετά να έρθει στο νέο να κάνει ενημέρωση; και πώς; με το νέο ή το παλιό id? (ξέρω αλλαγές φύλου δεν έχουμε κάθε μέρα, αλλά ένας οικονομικός μετανάστης κάποια στιγμή μπορεί να πάρει την ελληνική υπηκοότητα και κάποιος εργαζόμενος μπορεί να αλλάξει ταμείο (ΤΕΒΕ, ΙΚΑ))

papadi wrote:

1) Γνώμη μου είναι ότι αυτή είναι μια αρκετά custom διαδικασία και ότι αν θέλω να μπορώ να εισάγω στο σύστημά μου εργαζόμενους και από άλλα συστήματα (π.χ. άλλου πελάτη) πρέπει η διαδικασία μου να μην περιορίζεται από αυτό το ID. Π.χ. ένα άλλο σύστημα μπορεί να εξάγει και αυτό τις ίδιες πληροφορίες αλλά σαν ξεχωριστά πεδία σε ένα delimited αρχείο και όχι κωδικοποιημένες σε ένα ID. Επίσης άλλο σύστημα μπορεί να μην τις εξάγει καθόλου και να πρέπει να τις δώσει ο τελικός χρήστης.

συμφωνώ απόλυτα

papadi wrote:

2) Η απαίτηση όμως ότι αν η πληροφορία έρχεται από άλλο σύστημα δεν πρέπει να μπορεί να τροποποιηθεί από το δικό μου είναι αρκετά λογική.

Διαφωνώ, τις πληροφορίες σε ένα σύστημα τις έχουμε για να τις επεργαζόμαστε.

Ίσως το παράδειγμα με την κατηγορία ασφάλισης δεν ήταν κατάλληλο. Στην πραγματικότητα οι πληροφορίες που υπάρχουν στο ID δεν μπορούν να αλλάξουν ποτέ. Και ναι, αν για κάποιο λόγο αλλάξουν (π.χ. λόγω λάθους) αυτό θα γίνει στο αρχικό σύστημα.

Ναι, όντως τις έχουμε για να τις επεξεργαζόμαστε. Δεν το έθεσα σωστά. Δεν πρέπει να τις επεξεργάζονται όλοι οι χρήστες, κυρίως για την αποφυγή λαθών.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

agmarios wrote:

Είσαι παλικάρι, οι περισσότεροι και μάλλον κι εγώ δεν θα είμασταν τόσο ευγενείς.

Είπα να στείλω αυτό το thread και στον προϊστάμενό μου... οπότε έπρεπε να πω κάτι κομψό!!!

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

αν όι αλλαγές γίνονται στο παλιό σύστημα (για τα παλιά data) τότε μιλάμε για το θέμα του συγχρονισμού; οπότε μπαίνουν πολλά θέματα στη μέση, τι βάση χρησιμοποιείς, τι βάση χρησιμοποιεί το παλιό, τι δίκτυο υπάρχει, τι φόρτο έχει, κλπ κλπ

Αλλά το ερώτημα τι γίνεται αν αύριο έχεις 10 άλλους πελάτες που χρησιμοποιούν 10 διαφορετικά συστήματα παραμένει σε εκρεμότητα. Πάντως οι εταιρίες χρεώνουν τρελά ποσά για μεταφορά δεδομένων από παλιό σύστημα σε νέο.

Θα βοηθούσε αν ήσουν λίγο πιο συγκεκριμένος...

Είναι λίγο δύσκολο να κάνεις γενικευμένο σύστημα αν δεν ξέρεις ποιά είναι τα πιθανά σημεία στα οποία θα πρέπει να επεκταθεί. Πχ αν θες να φτιάξεις ένα σύστημα που να διαβάζει οποιοδήποτε τέτοιο proprietary ΙD και να κάνει map εξαγόμενες πληροφορίες σε πεδία της βάσης σου, τότε μπορώ να σκεφτώ ας πούμε τη δημιουργία ενός μηχανισμού με rules που θα γίνονται apply πάνω στα εισερχόμενα data. Τέτοια συστήματα υπάρχουν ήδη αλλά ακριβώς επειδή είναι πολύ generic, κοστίζουν και πολλά λεφτά (βλ. BizTalk Server). Πάντως εξέτασε και τη λύση του SQL Server Integration Services. Σου δίνει out-of-the-box τέτοια ευελιξία και άπαξ και φτιάξεις τον βασικό μηχανισμό, μετά μπορείς να τον προσαρμόζεις ανάλογα, για κάθε πελάτη.

---

Vir prudens non contra ventum mingit

Δεν νομίζω ότι θέλω να γίνω πιο συγκεκριμένος. Το ερώτημα είναι αρκετά φιλοσοφικό. Και οι απαντήσεις σας αρκετά σημαντικές! Όντως η λύση του sql server integration services είναι πολύ καλή, αν βέβαια έχεις sql server. Στην περίπτωσή μου, μάλλον ναι. Ή μια που μιλάμε για custom περιπτώσεις, μπορεί να χρησιμοποιηθεί όποτε υπάρχει.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Για να κάνεις τη διαδικασία του import λίγο πιο επεκτάσιμη, θα μπορούσες να εισάγεις ένα δικό σου data schema από το οποίο κάνεις εσύ την εισαγωγή, και στη συνέχεια να έχεις το μετασχηματισμό από το αρχικό σύστημα στη δική σου μορφή.
Αυτό το σχήμα μπορεί να είναι είτε ένας πίνακας, είτε ένα file format για πιο παλιά συστήματα τα οποία δουλεύουν έτσι τις γέφυρές τους ή αν δεν έχεις πρόσβαση στη βάση.
Καταλήγεις έτσι σε μια διαδικασία import, με το error handling και το χειρισμό των updates γραμμένο μια φορά, και τόσες διαδικασίες export από το αρχικό σύστημα στη δική σου μορφή όσες και οι εφαρμογές από τις οποίες αντλείς δεδομένα. Επίσης, αν το αρχικό σύστημα είναι άλλου κατασκευαστή με τον οποίο ο πελάτης σου έχει συμβόλαιο συντήρησης, μπορείς να τους σπρώξεις το κομμάτι του export και να ξεφορτωθείςπαραλληλίσεις έτσι τη δουλειά της "αποκωδικοποίησης" του περίεργου σχήματος που περιγράφεις.

---

Νατάσα Μανουσοπούλου

Νατάσα, όντως μιλάω για μια γέφυρα και όντως το σωστό είναι να λαμβάνει η εφαρμογή μου από συγκεκριμένο σημείο τα δεδομένα και όλες οι customιες να γίνονται σε μια άλλη διαδικασία που να γεμίζει το δικό μου προκαθορισμένο σημείο. Θυμίζει αρκετά αυτό: http://www.dofactory.com/Patterns/PatternBridge.aspx

Κάτι τέτοιο σκέφτηκα να υλοποιήσω και εγώ. Δείτε την επισύναψη. Περιέχει δυο xml. Το ένα περιέχει το schema για import από fixed length αρχείο που έχει κάποια πληροφορία κωδικοποιημένη στο ID (ίσως από ένα παλιό σύστημα), ενώ το άλλο κάνει import από από delimited αρχείο που έχει όλη την πληροφορία flat (ίσως από ένα πιο σύγχρονο σύστημα).

Ο κώδικας στο σύστημά μου λέει "δώσε μου το Sex" και ο κώδικας που κρύβεται πίσω βλέπει στο schema ότι π.χ. το αρχείο είναι utf-8, semicolon delimited και το sex βρίσκεται στη θέση 3. Αν πάλι το schema είναι διαφορετικό, βλέπει ότι το αρχείο είναι windows-1253, fixed length και ότι για να πάρει το sex πρέπει να εκτελεστεί ο custom κώδικας GetSex.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

(Χωρίς να έχω κοιτάξει τον κώδικά σου) Ναι, ένας τέτοιος μηχανισμός είναι απαραίτητος για μια generic λύση, ωστόσο έχε υπόψην αν αναπτύξεις ο ίδιος τη λύση, πέρα από το τεχνικό θέμα - πώς θα γίνει σωστά η δουλειά - υπάρχει και το θέμα του performance και του scalability που ενδεχομένως να σε απασχολήσει. Τα έτοιμα εργαλεία έχουν λύσεις. Πχ σε SSIS μπορείς να παίξεις με BulkInsert (και να κάνεις TableLock κατά το insert) για μέγιστο throughput ή να παίξεις με OLEDB Source, κλπ. Από την άλλη μεριά ο Biztalk έχει σχεδιαστεί ως Enterprise λύση και είναι πολύ scalable.

Μην με παρεξηγήσεις, δεν είμαι biased για τις έτοιμες λύσεις, απλά θα πρέπει να εξετάσεις όλες τις πλευρές της λύσης που θα επιλέξεις και να θέσεις την βαρύτητα που έχει κάθε χαρακτηριστικό για το case σου. Ας πούμε, τόσο τα SSIS όσο και ο Biztalk έχουν υπολογίσιμο learning curve καθώς και ανάλογο administration ενώ έχοντας αναπτύξει τη δική σου λύση (και γνωρίζοντας πως παίζει) είσαι έτοιμος να παίξεις κατευεθείαν. Είπαμε, είναι όλα θέμα trade offs.

---

Vir prudens non contra ventum mingit

Πολύ σωστά. Σκέφτομαι ότι αν αφαιρέσω τους μηχανισμούς custom κώδικα από την λύση μου τότε μπορεί αυτή να αποτελέσει απλά το front-end του συστήματός μου και τελικά το import να γίνει π.χ. από έναν biztalk. Το σημείο στο οποίο το σύστημά μου θα παραλαμβάνει τα δεδομένα θα είναι ο παραπάνω μηχανισμός, χωρίς όμως τους μετασχηματισμούς που θα έχουν γίνει πλέον στον biztalk.

Έχω λοιπόν απλά ένα layer στη διαδικασία import, το οποίο θεωρώ μικρό trade-off για την ευελιξία που μου δίνει.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Δημήτρη η ιστορία σου είναι "κλασική" περίπτωση... Είχα παρόμοιο ζήτημα, για να γεφυρώσω 2 συστήματα. Πιο συγκεκριμένα:

Γενικά οι ελληνικές εταρείες δεν έχουν HR συστήματα. Αλλά σίγουρα έχουν προγράμματα μισθοδοσίας. Τον τελευταίο καιρό όλο και περισσότερες όμως αποκτούν ένα HR πρόγραμα. Ένας από τους βασικούς σκοπούς ενός HR προγράμματος είναι να παρακολουθεί τους υπαλλήλους, την μισθοδοσία τους, τις θέσεις εργασίας που υπάρχουν μέσα σε μια επιχείρηση, και αφού οριστούν αυτές τα skills που έχει κάθε θέση, να μπορεί με την χρήση των ικανοτήτων και γνώσεών των υπαλλήλων να προτείνει υποψηφίους για μια θέση.

Η γεφύρωση εδώ έχει να κάνει με το οποιοδήποτε πρόγραμμα μισθοδοσίας, με το πρόγραμμα HR. Το δεύτερο ήταν βασισμένο σε Microsoft technologies και απαιτούσε SQL Server 2000, ενώ το πρόγραμμα μισθοδοσίας ήταν γενικά άγνωστο, όπως και τι τεχνολογία θα χρησιμοποιούσε. Το ζητούμενο ήταν μια φορά το μήνα, να εισάγωνται στο HR πρόγραμμα τα δεδομένα από το πρόγραμμα μισθοδοσίας αλλά ταυτόχρονα, να κρατούσε τα έξτρα δεδομένα που είχε το πρόγραμμα HR και ταυτόχρονα να μην χάνονται οι σχέσεις των δεδομένων, μετά από κάθε ενημέρωση.

Η πρώτη μας προσέγγιση ήταν να κάνουμε χρήση των Data Transformation Services, αλλά απότυχε όταν πήγε να εφαρμοστεί στο πελάτη.

Πολλοί πελάτες δεν είχαν SQL Server, και ήθελαν να κάνουν το έξοδο να αγοράσουν, μιας και το πρόγραμμα HR μπορούσε να τρέξει και σε MSDE. Δεν ήταν δυνατόν να τους αναγκάσουμε να αγοράσουν μόνο και μόνο για να μπορούμε εμείς να χρησιμοποιήσουμε Data Transformation Services. Μην πω για τους άλλους μισούς, που είχαν χρησιμοποιούσαν τεχνολογίες με flat files, που δεν υπήρχε ούτε ODBC για να συνδεθούμε επάνω τους.

Αυτό που δούλεψε, και δουλεύει ακόμα εδώ και 4 χρόνια τώρα, ένα custom πρόγραμμα που μεταφέρει δεδομένα από την μια εφαρμογή στην άλλη. Στην αρχή ήταν custom για τον κάθε πελάτη, αλλά μετά τους τρεις πρώτους, το πρόγραμμα μεταφοράς των δεδομένων απόκτησε μια markup γλώσσα/xml αρχείο που περίγραφε τα transformations που έπρεπε να γίνουν. Έτσι με μικρές αλλαγές κάθε φορά, η εφαρμογή μεταφοράς δεδομένων είναι έτοιμη για όποιο σύστημα, με την χρήση OLEDB/ODBC/csv αρχείων για εισαγωγή δεδομένων.

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Πολύ σημαντικό το σχόλιό σου Γιώργο! Ουσιαστικά αυτό που περιγράφεις στην τελευταία παράγραφο είναι ακριβώς αυτό που αποφάσισα να κάνω και εγώ, μάλλον για τους ίδιους λόγους. Αν δεις την επισύναψη που έχω παραπάνω θα δεις 2 παραδείγματα xml που περιγράφουν ακριβώς το transformation που πρέπει να γίνει. Αρχικά έχω δώσει την δυνατότητα για εισαγωγή από fixed length ή delimited αρχεία.

---

Dimitris Papadimitriou Software Development Professional

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Διαβάστε επίσης τους όρους χρήσης.

Τώρα που το είπες τα είδα...

Σου επισυνάπτω μερικά από αυτά που φτιάξει εγώ για import...

Και ένα σύντομο απόσπασμα για την ιστορία:

<recordset name="Accountability" type="Table">
 <try>
  <select name="Accountability">
   <where cause="AND">
    <field name="PartyID" type="uniqueidentifier" key="PositionPartyID" />
    <field name="AccountabilityValPartyID" type="uniqueidentifier" value="{D3426632-E0Ab-4F93-A854-3DB7A0CF55CE}" />
    <field name="AssociatedPartyID" type="uniqueidentifier" select="PartyID">
     <select name="Position">
      <where cause="AND">
       <field name="DepartmentCode" type="varchar" size="20" calculate="DepartmentCode">
        <calculate type="reportstoposition" field="DepartmentCode" />
       </field>
      </where>
     </select>
    </field>
   </where>
  </select>
 </try>
 <catch>
  <insert name="Accountability">
   <field name="PartyID" type="uniqueidentifier" key="PositionPartyID" />
   <field name="AccountabilityValPartyID" type="uniqueidentifier" value="{D3426632-E0Ab-4F93-A854-3DB7A0CF55CE}" />
   <field name="AssociatedPartyID" type="uniqueidentifier" select="PartyID">
    <select name="Position">
     <where cause="AND">
      <field name="DepartmentCode" type="varchar" size="20" calculate="DepartmentCode">
       <calculate type="reportstoposition" field="DepartmentCode" />
      </field>
     </where>
    </select>
   </field>
  </insert>
 </catch>
 <default />
</recordset>

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

gcapnias wrote:

Δημήτρη η ιστορία σου είναι "κλασική" περίπτωση... Είχα παρόμοιο ζήτημα, για να γεφυρώσω 2 συστήματα. Πιο συγκεκριμένα:

Ψοφάω από περιέργεια να μάθω ποια είναι τα συστήματα αυτά... Έρευνα ανταγωνισμού γαρ

---

Νατάσα Μανουσοπούλου