Soluzioni per l'automazione del job scheduling - WHITE PAPER
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
WHITE PAPER: Soluzioni per l’automazione del job scheduling SOMMARIO Capitolo 1: Perché dotarsi di una soluzione di job scheduling - Dieci domande da porsi Cosa comporta avere infrastrutture IT eterogenee Criticità di un sistema complicato Definizione di job scheduling Dieci domande da porsi Capitolo 2: Sette casi d’uso di job scheduling Sette storie di job scheduling Sette storie, sette esempi di valore aggiunto del job scheduling Capitolo 3: Analizziamo nel dettaglio un flusso di processi IT Un flusso di lavoro è un’attività IT Flussi di job e pianificazione dei processi Librerie di job e valore aggiunto dei trigger Capitolo 4: Enterprise job scheduling: una lista di requisiti da controllare Creazione dei requisiti specifici per il job scheduling Vincere nel mercato globale: il job scheduling alla base del successo Copyright @ ORSYP 2014 All Rights Reserved 2
WHITE PAPER: Soluzioni per l’automazione del job scheduling Capitolo 1: Perché dotarsi di una soluzione di job scheduling - Dieci domande da porsi Ricordo ancora il giorno in cui il mio capo mi chiamò nel suo ufficio e mi convinse ad intraprendere un nuovo progetto, il progetto che cambia ogni cosa. Disse: “Tu sei il mago degli script, saprai farlo funzionare “. Accettai la sfida e il resto è storia. La maggior parte dei grandi progetti nel settore IT inizia in questo modo, per cui forse conoscete già storie simili. Si tratta di progetti che sembrano validi sulla carta, ma poi diventano difficili e complessi quando si cerca di realizzarli, a causa della presenza di diverse applicazioni e piattaforme che richiedono tempo e risorse per integrarsi tra loro. Questa storia però non riguarda solo ciò che mi fu affidato quel giorno. Parla anche di tutte le piccole automazioni che vanno a comporre nel corso del tempo ogni infrastruttura informatica, come gli script per Windows, Oracle, Active Directory (AD), SQL, processi di sistema e così via. Sono automazioni in grado di risolvere esigenze immediate di business, ma che senza una gestione centralizzata rappresentano anche un centro di costo; un costo che aumenta quando la tecnologia diventa ormai obsoleta o gli sviluppatori lasciano l’azienda e si trasferiscono altrove. Allora ero stato riconosciuto come il “mago degli script”. Se aveste avuto bisogno di elaborare velocemente i dati, o di trasferire i file da un sistema all’altro, sarei stato la persona giusta da contattare. Avevo una perfetta padronanza del linguaggio di programmazione più importante del momento, e di tanti altri componenti aggiuntivi. Questo mi rendeva appunto il “mago” cui si era rivolto il mio capo. Avevo acquisito esperienza e abilità nel corso degli anni, ampliando la mia sfera di competenza fino ad includere tecnologie specifiche per piattaforme e applicazioni come WMI, ADSI, SQL, poi Oracle, Linux e IBM AIX. Per realizzare il progetto che mi era stato chiesto, ho messo in campo tutta la conoscenza del mestiere di cui disponevo. Nel corso degli anni avevo automatizzato gran parte delle mie attività. Certo, non sempre ogni cosa funzionava alla perfezione. A volte le automazioni venivano accidentalmente cancellate durante l’aggiornamento del datacenter, o non erano più necessarie e andavano riconfigurate. In altre parole, il meccanismo dell’automazione poteva essere migliorato. Infine, è venuto il giorno in cui ho cambiato lavoro, e quello è stato il problema maggiore per il sistema di automazione. Infatti, avevo sviluppato diversi script distribuiti in tutta l’azienda, senza alcun sistema centrale che li gestisse in modo unitario. Potevano perfino verificarsi criticità nei processi, senza che nessuno se ne accorgesse e potesse intervenire... Mancava qualcosa, questo era certo, e precisamente ciò che chiamiamo “job scheduling”, o meglio l’automazione del job scheduling. Lo scopo di questo documento è spiegare il significato della schedulazione delle elaborazioni e restituire il valore che essa può offrire in un contesto aziendale. Nelle pagine che seguono intendo illustrare più in dettaglio il grande progetto che il mio capo decise di affidarmi quel giorno di cui ho parlato all’inizio, fornendo alcuni esempi che chiariscono ulteriormente perché il “job scheduling” e l’automazione sono davvero centrali per il business di un’azienda. Copyright @ ORSYP 2014 All Rights Reserved 3
WHITE PAPER: Soluzioni per l’automazione del job scheduling Cosa comporta avere infrastrutture IT eterogenee Questo documento non esisterebbe se ogni tecnologia IT comunicasse perfettamente con le altre, se il trasferimento dei dati, il controllo degli eventi e i comandi su piattaforme e applicazioni fossero perfettamente integrati tra loro o con sistemi diversi. La schedulazione delle elaborazioni aziendali (o “job scheduling”) è un’esigenza comune a tutte le imprese, trasversale ai settori di business e alle dimensioni delle imprese. I “job” del job scheduling sono gli script di automazione. Alcuni funzionano con una sola applicazione, altri invece integrano servizi su più sistemi per creare un workload “misto”, in grado di soddisfare quelle che normalmente sono le esigenze aziendali immediate in un contesto cross-platform e cross-application. Tra i casi più comuni di job vi sono: • Report sulle attività di utilizzo della posta elettronica, che devono essere resi disponibili a chi si occupa di sicurezza • File trasferiti dai client in ingresso, per esempio ad un server FTP Linux, e che devono essere inseriti immediatamente in un database SQL • Applicazioni di posta elettronica e database per semplificare l’utilizzo di sistemi specifici • Nuovi record, ad esempio in un database Microsoft SQL o Oracle che innescano azioni in uno o più sistemi middleware Queste elaborazioni potrebbero essere più semplici e sicure se vi fosse un solo sistema o una sola applicazione di riferimento, in grado di gestire le diverse fasi di monitoraggio e verifica dei job. La complessità degli ambienti IT è dovuta anche al proliferare di differenti tecnologie che vi risiedono. Tali differenze rappresentano un problema all’interno dei datacenter di oggi. La vostra infrastruttura IT ha sicuramente sistemi Windows, ma forse anche Oracle, HP-UX, Solaris e altri. È probabile che sia necessario trasferire documenti XML, file DOCX, XLSX e fogli di calcolo su protocolli multipli come SMB, FTP e SSH. Anche i vostri sistemi di controllo e monitoraggio sono probabilmente disponibili su diverse tecnologie: SNMP per switch e router, WMI per i sistemi Windows, e tutti i vari widget UNIX e Linux per tenere sotto controllo le attività. Si possono immaginare alcune criticità che potrebbero sorgere in seguito alle differenze tra applicazioni e piattaforme negli ambienti ibridi di oggi: • Ogni sistema operativo (OS) possiede un linguaggio diverso dagli altri, e lo stesso vale per le applicazioni • Ciascuno di questi elementi utilizza il proprio modello di sicurezza, che non si integra con quello degli altri • Il trasferimento dei dati o le pianificazioni all’interno e tra i vari ambienti a volte risulta difficile, se non impossibile con gli strumenti nativi • Soprattutto, con gli strumenti nativi non è possibile gestire in modo centralizzato tutti i job La funzione principale di una soluzione di job scheduling è risolvere questi cinque problemi. Un unico pannello di controllo centrale permette di avere visibilità su tutte le elaborazioni del sistema, creando una singola piattaforma per l’automazione. Questo evita che singoli script per eseguire i job vengano distribuiti su sistemi differenti. Utilizzando una soluzione centralizzata è possibile controllare e armonizzare, ad esempio, le elaborazioni su database con job di sistema UNIX/Linux e job FTP. Le esecuzioni sono avviate dallo stesso punto, e tutti i sistemi sono gestiti e monitorati da un’unica postazione. Copyright @ ORSYP 2014 All Rights Reserved 4
WHITE PAPER: Soluzioni per l’automazione del job scheduling Job scheduling per centralizzare job su qualsiasi piattaforma e applicazione Una soluzione di automazione di job scheduling deve essere eccezionalmente completa. Non basta che supporti la gestione, il monitoraggio e il flusso delle elaborazioni. Deve anche implementare le integrazioni con i diversi sistemi operativi, le piattaforme e le tecnologie incorporate dai processi aziendali. Per questo, trovare la giusta soluzione è importante e al tempo stesso impegnativo. Si può considerare questo documento come una “fabbrica di idee per l’automazione”. Nel prosieguo di questo lavoro verranno proposte alcune domande di auto-valutazione, che vi aiuteranno a capire meglio le esigenze a cui una soluzione di job scheduling risponde. Vedremo una serie di casi reali di utilizzo e potremo analizzare il meccanismo di un job informatico, in modo da comprendere appieno la potenza di una soluzione centralizzata. Questo documento si conclude con una lista di requisiti da prendere in considerazione nella scelta del software adatto a soddisfare le necessità aziendali. Cercherò di essere la vostra guida, e durante il viaggio che stiamo per iniziare condividerò alcune delle mie storie per dimostrare con esperienze reali la validità di quello che sosterrò. Nota: Nel presente documento utilizzerò il termine “job scheduling”. Un altro termine comunemente impiegato per indicare la pianificazione dei processi è “automazione del carico di job”. Ai fini di questo lavoro, si possono intendere i due come equivalenti. Criticità di un sistema complicato Torniamo ora alla mia storia di tanto tempo fa. Ogni applicazione e ogni sistema operativo sono in grado di eseguire le rispettive funzioni in diversi modi; ad esempio, un sistema operativo può includere uno o più linguaggi per scrivere e leggere i dati, così come ogni database moderno è dotato di funzioni di automazione e pianificazione per l’inserimento o la selezione dei dati. Anche le tecnologie middleware e varie applicazioni sono dotate di API proprietarie, che possono essere utilizzate come interfaccia all’esterno dell’applicazione. Tuttavia, queste funzionalità, insieme alle automazioni già presenti nei prodotti, raramente sono in grado di gestire le interazioni al di fuori dei prodotti stessi. Avete mai provato ad utilizzare un documento XML per indicare ad un server SQL che deve aggiornare una riga di database Oracle, in modo che un’applicazione SAP possa eseguire il controllo di un processo su un server AIX? Tutto questo assomiglia alla situazione in cui mi sono trovato all’inizio del progetto che mi aveva affidato il mio capo. Il motivo per il quale quel progetto era necessario, in fondo non conta molto. L’importante è invece sapere che il nostro sistema era costituito da una miriade di elementi disparati, con diverse applicazioni in esecuzione all’interno del sistema operativo, e con database anch’essi diversi, alimentati da dati provenienti sia dall’interno che dall’esterno della compagnia. E tutto questo era solo l’inizio... Per cominciare, ho cercato lo schema dei componenti del sistema. Ad un livello alto, esso era stato costruito per aggregare dati esterni all’azienda con dati provenienti dall’interno. Il nostro problema era che i dati dovevano essere trasferiti in molti luoghi diversi... Copyright @ ORSYP 2014 All Rights Reserved 5
WHITE PAPER: Soluzioni per l’automazione del job scheduling Com’era gestito il flusso di dati nel sistema dell’azienda dove lavoravo Il flusso di dati nel sistema della mia azienda veniva gestito tramite FTP da una sorgente esterna. Questi dati e tutti i metadati relativi dovevano essere depositati in un unico database centralizzato SQL. Alcuni erano disponibili in base ai profili di utenza, mentre non si poteva avere accesso ad altri. Le informazioni contenute all’interno del flusso di dati FTP erano utili ad identificare chi poteva avere accesso a cosa. Gli utenti erano in grado di interagire con i dati tramite un server Microsoft IIS che eseguiva un’applicazione Web realizzata internamente. Tale applicazione utilizzava il formato XML per trasferire dati da e verso il database SQL. A volte, i dati venivano elaborati da un server UNIX, che effettuava il consolidamento con le informazioni provenienti da altre sorgenti o da aree aziendali diverse. Un server di posta garantiva l’inoltro di notifiche agli utenti sugli aggiornamenti, lo stato dei set di nuovi dati o altri eventi. Vi erano quindi di numerose correlazioni, con le relative integrazioni che andavano gestite in modo adeguato per garantire il funzionamento di tutto il sistema. I processi dovevano essere avviati in sequenza, armonizzando per esempio le elaborazioni sui server e sui database. In una situazione del genere, risultava complesso e impegnativo anche solo pianificare le integrazioni di ogni correlazione di job. Vi sembra per caso di vedere qualcosa di simile anche nel vostro datacenter? Potrebbero esserci situazioni analoghe se si elaborano o si trasferiscono grandi volumi di dati all’interno dell’azienda. È bene quindi valutare i seguenti quattro punti critici: • Sistemi interconnessi come questo esistono ovunque, in qualsiasi compagnia. Altri hanno quindi già avuto a che fare con gli stessi problemi d’integrazione in diversi contesti, ed è consigliabile trarre vantaggio dalla loro esperienza. • Costruire e gestire un sistema simile non è necessariamente un’attività per soli sviluppatori. Io stesso non lo sono. Il mio ruolo è quello di amministratore di sistema, cui è capitato di essere considerato “Il mago del computer”, e perciò il candidato ideale cui affidare questo progetto. Gli amministratori devono costruire sistemi composti da molte parti, in grado di “parlarsi” tra loro. Programmare le attività è solo il primo passo di questo cammino. • È possibile realizzare un sistema completo e funzionale utilizzando gli strumenti di automazione specifici di ogni singolo componente, ma questa non è una buona idea. Le mie elaborazioni producevano VBScript e cron job, file SSIS-SQL e ciò non è mai stato utile ai fini della gestione complessiva; al contrario, ha solo creato confusione e problemi. La programmazione delle attività è efficace a lungo termine solo se centralizzata, e la manutenzione delle automazioni è più semplice e sicura se le attività sono ridotte di numero. • Azioni semplici all’interno di sistemi semplici possono funzionare bene con null’altro che ora e data di pianificazione. Ma sistemi più complessi o che presentano più dipendenze hanno bisogno di mezzi potenti per determinare quando fare qualcosa. Queste decisioni possono essere prese in base alla ricezione di dati o a modifiche nel database, alla lettura di file log o ad un altro evento che può verificarsi nel sistema. Una buona soluzione di job scheduling offrirà diverse condizioni personalizzabili per definire quando un’azione dev’essere eseguita. L’insieme di questi quattro elementi mi suggerì di guardare a soluzioni per la pianificazione delle attività attraverso tutte le piattaforme e tutte le applicazioni. È stato allora che ho iniziato a cercare soluzioni di pianificazione dei processi IT. Copyright @ ORSYP 2014 All Rights Reserved 6
WHITE PAPER: Soluzioni per l’automazione del job scheduling Definizione di job scheduling Facciamo ora un passo indietro, e riflettiamo sul significato di “job scheduling”. Ho cercato di spiegare che un “job” è una sorta di automazione, che si verifica all’interno di un’infrastruttura IT. Una definizione più tecnica è che esso rappresenta l’azione da compiere: potrebbe essere l’esecuzione di un file batch o di uno script, di un comando “shell”, di un processo su un database, o l’elaborazione di una serie di dati. In sostanza, tutto ciò che produce un cambiamento in un sistema è collegato a un’entità che chiameremo “job”. Nell’utilizzare un approccio informatico orientato agli oggetti, è opportuno consolidare le singole azioni in job separati. Questo approccio singola-azione-per-job garantisce che i processi siano riutilizzabili altrove e per altri scopi. In sostanza, che sia possibile creare un processo chiamato ad esempio “Connessione al database Oracle”, ed utilizzare quel job ogni volta che si ha bisogno di fare una connessione al database Oracle. Se ogni job compie una semplice azione, è possibile unire più job per completare un processo. Chiameremo questo processo “IT plan”, ovvero una pianificazione che rappresenta una serie di job correlati, i quali possono essere eseguiti per raggiungere l’obiettivo voluto: l’effettuazione di modifiche strutturali all’interno di un sistema. Creare dei buoni job è quasi un’arte, perché essi non devono necessariamente contenere informazioni specifiche memorizzate all’interno dello script, come il nome del server o la cartella a cui si fa riferimento. Un approccio migliore è quello di utilizzare una variabile. Gli sviluppatori utilizzano la parametrizzazione per generalizzare gli oggetti contenuti nei job, e questi parametri vengono successivamente applicati in fase di esecuzione. Scegliere i parametri giusti rende possibile collegare diversi job generici. Nel momento in cui viene eseguito l’“IT plan” frutto di tale collegamento, vengono inoltrate ai job le informazioni sulle variabili di cui hanno bisogno, ad esempio per la connessione al database, al fine di estrarre da esso i dati corretti e trasferire altrove i file in formato FTP. Riutilizzazione e pianificazione dei job Tramite la parametrizzazione dinamica della pianificazione, si rendono riusabili tutti i processi. Ad esempio: occorre cambiare il database a cui connettersi, o estrarre un gruppo di dati diverso, o ancora inviare questi dati ad un altro server FTP? È possibile fare tutto ciò semplicemente modificando le informazioni contenute nelle variabili. Questo è quanto si definisce riusabilità. Si potrebbe parlare molto più a lungo di job e pianificazioni. Nel Capitolo 3, cercheremo di capire meglio le varie caratteristiche che può avere un job, e approfondiremo la conoscenza degli altri oggetti che vengono impiegati in una tipica soluzione di “job scheduling”. Prima di proseguire, vi è però un aspetto che merita maggiore attenzione: quello della schedulazione. Essa definisce quando un job deve essere eseguito. La schedulazione dei sistemi richiede una certa flessibilità. Non può essere legata strettamente ad un tempo determinato in cui avviare l’elaborazione. Piuttosto, i job sono legati ad eventi o cambiamenti di stato che si verificano all’interno dell’infrastruttura informatica. Supponiamo di dover trasferire dati da SQL Server ad un server UNIX. Potrebbero essere definite tre diverse schedulazioni dell’IT plan che abbiamo elaborato per realizzare il processo: • Eseguire il trasferimento alle 3:00 PM • Eseguire il trasferimento quando arrivano nuovi dati • Eseguire il trasferimento quando l’utilizzo del processore è inferiore al 30% Uno qualsiasi di questi tre tipi di schedulazione può essere adeguato, dipende dalle esigenze. Il primo soddisferebbe le richieste di una “raccolta dati giornaliera”. In questo caso, la schedulazione con data/ora sarebbe adatta allo scopo e molto semplice. Copyright @ ORSYP 2014 All Rights Reserved 7
WHITE PAPER: Soluzioni per l’automazione del job scheduling Nel secondo caso, il processo si attiva solo quando vengono ricevuti nuovi dati. Questa soluzione è interessante quando si vogliono mantenere i database sincronizzati tra loro, in particolare se si considera la difficoltà di ottenere un risultato simile nel caso venissero utilizzati unicamente il SQL nativo e gli strumenti del sistema UNIX. La terza soluzione è ingegnosa perché potrebbe venire impiegata sia da sola, sia in combinazione con il secondo caso appena visto. Le elaborazioni si attivano solo se il server non è molto utilizzato. Combinato con la seconda modalità, ciò permette di mantenere la sincronizzazione tra i componenti del sistema senza però sovraccaricare il server. Una buona soluzione di job scheduling include una vasta gamma di condizioni applicabili alle pianificazioni dei job, in modo che le elaborazioni vengano avviate quando e come previsto, in base alle necessità aziendali. Dieci domande da porsi Avremo nuovamente occasione di immergerci nel funzionamento dei componenti di un flusso di job nel capitolo 3. Ma prima di poter veramente apprezzare la potenza di questo approccio modulare, forse è il caso di rispondere ad alcune domande che vi starete probabilmente ponendo. E se non lo state facendo, lasciate che io stesso vi aiuti con un elenco di dieci quesiti che ognuno dovrebbe porsi sulla propria infrastruttura IT. I. Quanto tempo avete perso per completare i processi manualmente? Non molti anni fa, tra i miei compiti vi era l’aggiornamento di una serie di server. Questa attività era mensile e obbligatoria, e richiedeva di essere svolta in modo sempre più rapido. Ogni aggiornamento andava eseguito in una finestra temporale molto breve. Il problema era che questi aggiornamenti richiedevano un riavvio del server per diventare effettivi. All’epoca la nostra finestra di riavvio era configurata nelle prime ore del mattino. Effettuare un giro di aggiornamenti una volta al mese comportava alcuni disagi. Per questo avevo creato uno script di automazione che includesse l’installazione degli aggiornamenti. La soluzione prevedeva che essi fossero implementati a partire dalla data valida successiva. Nel caso si fossero verificati problemi, avrei ricevuto notifiche tramite messaggi sul cellulare. In tal modo, gli aggiornamenti erano diventati più semplici da gestire. L’unica cosa a cui dovevo stare attento era di avere sempre il cellulare a portata di mano per essere informato su eventuali criticità. A volta capitava che qualcosa andasse storto, ma spesso era risolvibile con un sessione di controllo remoto. Gli aggiornamenti eseguiti con successo mi permettevano di non perdere tempo - né sonno durante la notte. A prescindere dal mio caso specifico, ciò che conta è il risparmio di tempo e denaro. I computer sono stati progettati per essere macchine automatiche, e ogni attività manuale andrebbe essa stessa ottimizzata attraverso l’automazione. Ci si può permettere il lusso di errori umani nelle attività critiche di un’azienda? Se la risposta è negativa, allora la soluzione può davvero risiedere nella creazione di flussi di job flessibili e riutilizzabili, attraverso un sistema di job scheduling adatto alle esigenze specifiche di un’impresa. II. Qual è il costo degli errori che si commettono durante un processo manuale? Questa domanda introduce alle principali categorie di rischio presenti in qualsiasi sistema manuale. La prima categoria è quella delle esecuzioni inappropriate. Ogni compito che richieda un intervento manuale implica il rischio che potrebbe venire eseguito in un momento inopportuno. O peggio, che tale compito possa essere ri- parametrizzato inviando i dati dove non devono essere inviati, o eseguito in modo improprio. Simili errori comportano un costo. Copyright @ ORSYP 2014 All Rights Reserved 8
WHITE PAPER: Soluzioni per l’automazione del job scheduling Ricordo ad esempio una situazione in cui era stato creato uno script che si applicava ad una serie di dati all’interno di un server specifico al momento dell’esecuzione. Lo script aveva come parametro un elenco di server a cui inviare i dati. Un giorno, un amministratore non molto esperto eseguì accidentalmente lo script con il carattere jolly “*” al posto di un elenco specifico di server. Come risultato, i dati furono distribuiti a tutti i server dell’azienda. Quella singola operazione ha creato un danno economico alla società, comportando alcuni costi per cancellare i dati inviati. Oltre alle esecuzioni inappropriate, tra gli altri rischi che possono essere indirizzati da una soluzione di job scheduling vi sono ad esempio dimenticanze ed errori umani di vario tipo. Ma grazie a questa soluzione, i job ed i flussi di elaborazione vengono eseguiti correttamente entro i confini del sistema e del suo perimetro di sicurezza, garantendo il controllo sulle operazioni rischiose, per esempio rendendo impossibile l’esecuzione a determinati profili di utenza. Centralizzare la sicurezza delle esecuzioni dei job assicura la protezione dell’ambiente elaborativo contro queste categorie di errori manuali. III. In che modo è possibile visualizzare le attività di un server? Probabilmente avrete già uno strumento di monitoraggio dei server, così come un sistema di controllo dei componenti di rete. Ma nel vostro datacenter esiste anche una vista centralizzata per il controllo dei processi? Un errore legato ai job può causare interruzioni o problemi di servizio, analogamente ad un guasto della rete o dei server. Se i vostri sistemi aziendali utilizzano programmi di pianificazione attraverso più prodotti e piattaforme, non state centralizzando tutte le attività in un’unica schermata. Centralizzare è possibile, e diventa semplice e funzionale se viene fatto con gli strumenti giusti. Ogni attività in qualunque sistema e applicazione può essere centralizzata in un unico schermo. In questo modo si può verificare lo stato di ogni job gestendo tutto da un unico punto. IV. Come si può migliorare la comunicazione tra i server? I moderni datacenter sono già dotati di strumenti di pianificazione, e molti tool aziendali possiedono sistemi di scheduling delle proprie attività. Il problema è che ognuno di questi strumenti e sistemi utilizza linguaggi diversi, per cui in pratica è molto difficile che possano efficacemente comunicare e scambiarsi dati tra loro. SQL, per esempio, è dotato di una vasta gamma di strumenti per modificare i dati del proprio sistema e di SQL Server, ma questo basta per l’inoltro di dati ad un server UNIX? Spesso, gli strumenti nativi non sono sufficienti e c’è bisogno di una soluzione diversa per ottenere le performance desiderate. Questa soluzione può essere sia un singolo “script di automazione” - come gli script di cui abbiamo parlato all’inizio di questo capitolo - oppure una pianificazione olistica, globale dei job. Nel capitolo 4 vedremo più da vicino le funzionalità che dovrebbe offrire la soluzione migliore per ogni esigenza aziendale. V. È possibile gestire meglio i tempi di inattività del sistema? Piattaforme e applicazioni di norma utilizzano specifici strumenti di pianificazione, cosa che tuttavia non le mette in grado di eseguire elaborazioni sulla base di azioni o cambiamenti di stato. In particolare, la verifica del tempo impiegato per effettuare le elaborazioni è un elemento difficile da misurare per tutte le piattaforme. Flussi di dati che non vengono processati come dovrebbero, o che risultano difficili da trasferire all’interno di un sistema, possono causare criticità all’intera pianificazione aziendale. Quando i processi non vengono completati nel modo corretto, allora si producono effetti a catena sulle attività a valle: questi effetti possono includere tempi di attesa nelle elaborazioni o altre conseguenze nel sistema della pianificazione. La durata di un processo non costituisce un problema se è prevista all’interno delle attività, o se non è ancora stato definito quando una persona dovrà inviare file o quando i dati saranno pronti per la fase successiva nel processo di elaborazione. Copyright @ ORSYP 2014 All Rights Reserved 9
WHITE PAPER: Soluzioni per l’automazione del job scheduling Tuttavia, gli stati di inattività sono difficili da gestire al meglio in assenza di uno strumento di schedulazione adeguato, che comprenda la pianificazione degli eventi. Con una schedulazione solamente temporale, i job vengono definiti senza possibilità di gestire i cambiamenti che possono verificarsi all’interno del sistema. Semplicemente, le elaborazioni verranno eseguite quando era stato pianificato. Una soluzione completa di job scheduling, invece, soddisfa veramente le esigenze aziendali perché include la gestione degli eventi (“on event scheduling”), le variazioni di stato o la possibilità di schedulare a richiesta le elaborazioni (“trigger-based scheduling”). Il sistema “on event”, per esempio, riconosce quando un cambiamento è stato effettuato e avvia la fase successiva di elaborazione. VI. Quante attività sono in corso nel vostro datacenter? Se non avete ancora implementato o standardizzato la schedulazione dei vostri processi, siete in grado di conoscere quante attività sono in corso nel vostro datacenter? Io sapevo dove si trovavano i processi che avevo creato, ma un giorno ho cambiato lavoro, e quella conoscenza è venuta via con me. Come ho già accennato, quei job sono stati ritrovati anni dopo, spesso in seguito a criticità nelle elaborazioni o a tempi di fermo del servizio. Inoltre, mi sono riferito solo ai miei script, ma vi erano anche altre persone che avevano creato i loro script. Così, alla fine, ulteriori informazioni sono andate probabilmente perse. Una soluzione centralizzata di job scheduling permette di definire un unico punto di controllo per tutta l’automazione. Mette in grado i team IT e il personale specializzato di sapere dove sono state apportate modifiche ai processi, e chi lo ha fatto. In questo modo tutto è più chiaro e i flussi elaborativi scorrono meglio all’interno del sistema. VII. Si possono monitorare i flussi di lavoro suddividendoli per tipologia, piattaforma e applicazione? Se non è possibile implementare una soluzione di questo tipo, si corre il rischio di creare solo confusione. E nella confusione, ognuno tende a scaricare la responsabilità sugli altri. Una volta mi hanno raccontato la storia di una società che aveva bisogno del job scheduling. Il loro sistema assomigliava al progetto che il mio capo mi aveva affidato, in quanto includeva tecnologie e piattaforme diverse tra loro. La gestione del sistema non era unificata nemmeno in quel caso, bensì distribuita: un team era dedicato a SQL Server, un altro alla piattaforma SAP e così via. Anche l’AD aveva il suo proprio gruppo di addetti. Il problema in quel caso non risiedeva nell’applicazione di strumenti specifici di pianificazione, ma nel personale. I vari team nutrivano una certa diffidenza verso la centralizzazione su cui si fonda una soluzione di job scheduling. Vi era il timore di dover ricreare i job SQL, SAP, AD e altri su un sistema nuovo, diverso da quello cui si era abituati, e fuori dal controllo dei vari gruppi. Per essere davvero efficiente e semplice da utilizzare, in una parola funzionale, una soluzione di job scheduling non deve richiedere la completa ri-creazione di job esistenti su ogni piattaforma o applicazione. Il job stesso rappresenta infatti il cambiamento che dev’essere fatto, o lo script individuale che dev’essere eseguito. Una soluzione di job scheduling rappresenta il wrapper centralizzato che permette di richiamare tutte le elaborazioni. Questa storia si conclude con la scoperta, da parte dell’azienda, che la centralizzazione è proprio ciò che serve. Un problema apparentemente minuscolo in un sistema si era infatti trasformato in qualcosa di ben più grande, perché l’azienda non era ancora in grado di gestire le elaborazioni in modo unitario. L’esperienza è servita per abbracciare la logica del controllo globale d’impresa nella schedulazione dei job. Copyright @ ORSYP 2014 All Rights Reserved 10
WHITE PAPER: Soluzioni per l’automazione del job scheduling VIII. Costruire o acquistare? Avevo scritto il mio sistema di schedulazione nell’ormai datato linguaggio di VBScript, ampiamente utilizzato in molti sistemi ma noto per non avere strumenti di pianificazione ad alto livello. Lo schedulatore ha funzionato bene per il compito che gli era stato assegnato. Tuttavia, la volta dopo mi serviva esattamente quel tipo di schedulazione complessiva che il mio strumento non poteva offrire. Dovetti perciò riscrivere il programma, ma anche con la modularizzazione del codice VBScript la riusabilità del mio scheduler era molto limitata. Immaginate di dover replicare la pianificazione su tutte le applicazioni e le piattaforme aziendali, che utilizzano linguaggi diversi. Gli script creati dal team IT possono gestire le esigenze di attivazione dei singoli job, ma ad un livello più alto solo uno scheduler è in grado di lavorare bene in tutti gli ambienti e con tutte le applicazioni. Inoltre, per realizzare uno scheduler sono necessarie molte più risorse di quello che si potrebbe immaginare. È infatti necessario controllare gli script che devono essere eseguiti, anche in base a dove li si vuole eseguire. Vi sono poi una serie di costi aggiuntivi, inclusi il tempo che implica la scrittura del programma. Tutto questo viene ovviamente sottratto ad altre attività a maggior valore aggiunto, cui le risorse potrebbero invece essere destinate. IX. Come si possono collegare i risultati di un job alle elaborazioni di quello successivo? In ogni sistema distribuito, i job dipendono l’uno dall’altro. Un job elabora una serie di dati che poi saranno necessari per l’attività successiva. La condivisione di dati può essere gestita da file scambiati tra job, oppure da meccanismi più complessi come Microsoft Message Queue o da trigger del database. Analogamente a quanto avviene per il problema di più linguaggi diversi tra i sistemi e le piattaforme, i metodi basilari per condividere i dati possono risolvere criticità contingenti, ma normalmente non sono adeguati a gestire la comunicazione tra piattaforme differenti. Diventa ad esempio difficile quando si utilizza un trigger di database richiamare un’azione in AD. Al contrario, una soluzione centralizzata per la pianificazione delle elaborazioni diventerà il punto centrale di controllo di tutte le interazioni e le dipendenze tra processi. X. Come si gestiscono gli errori in un processo personalizzato? La gestione dei messaggi di errore degli script è un processo delicato, che richiede tempo in fase di sviluppo e design dello stesso script. Gli errori sono difficili da individuare, soprattutto quando gli script sono distribuiti su piattaforme e applicazioni diverse. Gestire gli errori richiede competenze specifiche nell’intercettazione e verifica delle variabili, oltre alla determinazione dei loro valori presunti e reali. Il quadro si complica ulteriormente quando gli script vengono eseguiti in modalità automatica, perché spesso le criticità non vengono rilevate. Nel capitolo 2 cercheremo di illustrare meglio la gestione di errori e funzionalità all’interno di un job scheduler. Per ora, limitiamoci a rilevare che questo ambito è fondamentale per la risoluzione dei problemi che possono verificarsi durante l’esecuzione di uno script. È bene quindi dotarsi di soluzioni IT per indirizzare tali necessità. Con le nozioni di base esposte in precedenza e le risposte alle domande iniziali, il prossimo capitolo introdurrà sette casi d’usi reali di automazione IT e di pianificazione dei processi. Questo dovrebbe fornirvi spunti interessanti, in quanto i casi d’uso che verranno descritti sono probabilmente simili alla vostra situazione attuale. Whether expanding into new geographies or establishing a new product line, implementation costs can be dramatically reduced with a distributed architecture solution. IT Operations can abstract existing process execution profiles, configurations, and templates for use when moving into a new market. With a distributed architecture approach, IT Operations has the ability to execute jobs in the Cloud, on virtualized systems or in-house and the option to transparently integrate the new workload with other core business application processing. Copyright @ ORSYP 2014 All Rights Reserved 11
WHITE PAPER: Soluzioni per l’automazione del job scheduling Capitolo 2: Sette casi d’uso di job scheduling L’unico business che non ha bisogno di automazione dei processi IT è quello che utilizza una sola applicazione. Tutte le altre aziende ne hanno bisogno. La maggior parte dei datacenter usa molto più di una singola applicazione su un’unica istanza. Un datacenter di medie dimensioni esegue applicazioni per la gestione dei propri database, e si avvale di sistemi middleware per l’elaborazione dei dati. In una simile struttura le elaborazioni vengono eseguite su sistemi operativi (OS), mainframe e pc: tutti elementi che hanno bisogno di comunicare tra loro, pur non condividendo lo stesso sistema operativo e utilizzando set di strumenti specifici. Oggi, alcune tecnologie si automatizzano da sole, ma è raro che due o più applicazioni siano in grado di comunicare tra loro. Ancora più raro è che il singolo prodotto possa definire e pianificare automaticamente i flussi di lavoro che soddisfano le esigenze di business. È perciò necessario integrare tra loro le diverse tecnologie, e si può fare questo solo attraverso una soluzione centrale che armonizzi tutte le applicazioni. Quello di cui abbiamo bisogno è una soluzione di job scheduling che faccia da “Rosetta Stone” - Stele di Rosetta - tra diverse piattaforme, sistemi operativi e applicazioni: una soluzione per il datacenter finalizzata a convertire i dati grezzi nei processi aziendali, in modo da estrarre reale valore per il business consegnando le informazioni giuste alle persone giuste. In questo documento, tenterò di mostrare come sia possibile integrare una soluzione simile nella propria azienda. Abbiamo visto in precedenza come potrebbe funzionare una schedulazione IT, per dimostrare come tali soluzioni siano necessarie alla vostra infrastruttura informatica. Tuttavia, non abbiamo ancora esaminato approfonditamente caratteristiche e potenzialità del job scheduling per qualsiasi tipo di azienda. Non ne tratteremo in questo capitolo, perché il modo migliore per illustrare il meccanismo della schedulazione dei job è di far luce sulle criticità che può risolvere. Una volta compreso come è possibile utilizzarlo per migliorare i processi aziendali, si può davvero apprezzare la logica in base alla quale funziona la soluzione. Mi auguro che possiate comprendere come il progetto che mi affidò il mio capo possa essere utile anche a voi, e che vi stiate convincendo della necessità di adottare una soluzione di automazione nel vostro datacenter. Sette storie di job scheduling Quello che voglio fare ora è tentare di fornire alcune idee per aiutarvi a capire meglio cosa può essere più adatto alle vostre esigenze. Presenterò queste idee nella forma di sette casi d’uso, in sostanza sette piccole “storie” sulle criticità che sono state risolte grazie ad una soluzione di job scheduling. Queste storie sono in parte fittizie, tuttavia si basano su necessità reali e offrono soluzioni anch’esse reali ai problemi che affrontano. Per mantenere la narrazione interessante, utilizzerò nomi falsi. Copyright @ ORSYP 2014 All Rights Reserved 12
WHITE PAPER: Soluzioni per l’automazione del job scheduling Caso 1: Cinque amministratori di sistema - cinque gestioni differenziate La prima storia illustra la situazione amministrativa dell’Azienda A, una società matura e affermata sul mercato, che però non possiede un’organizzazione IT altrettanto solida. Manca infatti un controllo centralizzato dei processi, e le configurazioni del sistema sono gestite da cinque diversi amministratori. Il datacenter stesso è composto da differenti aree e silos, che però hanno bisogno di comunicare tra loro. I cinque amministratori IT sono John, Bob, Jane, Sara, e Jim . Ognuno di loro gestisce una parte dell’infrastruttura del datacenter, e le responsabilità di ciascuno si sovrappongono in qualche modo a quelle degli altri. I cinque addetti hanno creato script e applicativi per i flussi di lavoro della propria area di competenza, ma queste automazioni non sono connesse tra loro. Automazioni non connesse Manca in sostanza un contesto generale che organizzi le varie automazioni. Per esempio, se John crea un processo, i suoi dati non possono essere basati su quelli di un altro processo creato da Sara. Come risultato, non c’è modo di orchestrare le attività di tutti gli amministratori, né di pianificare le elaborazioni in modo che non siano in conflitto, né di definire un processo a conclusione dei risultati di un processo precedente eseguito da un amministratore diverso. Soluzione: un sistema unico per consolidare le automazioni La soluzione risiede nel consolidamento delle automazioni di queste cinque persone in un sistema unico e centralizzato. Solo così i job di ognuno possono essere visti anche dagli altri. Le elaborazioni di ciascun singolo amministratore possono inoltre venire allineate alle esigenze di tutti, per garantire una gestione più equilibrata ed efficiente delle risorse. Infine, grazie al fatto che tutti i processi risiedono in un unico luogo, è semplice riutilizzare i dati e gli strumenti di ogni automazione anche nelle pianificazioni future per effettuare altre elaborazioni. Una soluzione di job scheduling è quindi adatta a pianificazioni di natura amministrativa oltre a quelle legate ad altri aspetti del business. Caso 2: Conflitto tra le attività dei sistemi Una soluzione di schedulazione informatica non si basa esclusivamente sugli operatori, anzi ha più a che fare con i dati di un datacenter. È per questo che la seconda storia si riferisce alle diverse applicazioni utilizzate dall’Azienda B. In particolare, il caso d’uso riguarda la linea di business di un’organizzazione (Line-of-Business, LOB), intesa come le applicazioni essenziali che compongono il sistema dell’azienda. La LOB è formata da diversi componenti, la comunicazione tra i quali viene regolata attraverso un’attenta orchestrazione a livello di attività, processi e flussi di lavoro. Il sistema nel suo complesso comprende sistemi operativi differenti, Windows e UNIX, e diverse tipologie di database, middleware e altri componenti. Sistemi e applicazioni differenti Tutti questi elementi attivano funzionalità messe a disposizione dalla LOB. Oltre a ciò, utilizzano il proprio set di strumenti per svolgere le attività pianificate: il server SQL esegue i pacchetti SSIS, il server Linux SAP esegue i propri processi ed i job di tipo Crontab, e anche il server “Informatica” esegue i suoi flussi di lavoro. In questa configurazione, uno schedulatore per componente può funzionare per la maggioranza delle LOB. I dati e le elaborazioni relative ad Informatica possono essere definiti in base al tempo e ad altre caratteristiche di pianificazione, il database SQL può eseguire i suoi pacchetti SSIS grazie alle proprie impostazioni personalizzate, e così via. Ma, analogamente a quanto abbiamo visto nel primo racconto, in questo ambiente è probabile che si verifichino problemi di conflitto delle attività individuali con quelle di altri sistemi. Copyright @ ORSYP 2014 All Rights Reserved 13
WHITE PAPER: Soluzioni per l’automazione del job scheduling Soluzione: un unico pannello per pianificare i job Una soluzione centralizzata di schedulazione delle elaborazioni è la risposta a questi problemi, perché sostituisce con un unico pannello la pianificazione individuale di ciascuna applicazione, e armonizza lo scambio di dati tra le piattaforme all’interno del sistema. Grazie alla centralizzazione dei dati e delle elaborazioni, viene migliorata la pianificazione delle attività e le varie fasi di acquisizione e trasformazione dei dati si collegano meglio tra loro. Il sesto caso che verrà presentato in questo capitolo illustrerà più in dettaglio come i processi innescati in modalità automatica migliorino sensibilmente le prestazioni del servizio. Per ora evidenziamo invece come la scelta di centralizzare la pianificazione porti a gestire meglio tutti i job all’interno dell’infrastruttura. Caso 3: Riutilizzo dei job per nuove attività di business John è un DBA Oracle che ha sempre lavorato presso l’Azienda C, dove si trova attualmente. Nella sua veste di amministratore di database, ha costruito per la società l’infrastruttura IT quasi da zero. Conosce quindi molto bene l’intero sistema, e col tempo ha apportato miglioramenti per aumentare le prestazioni ed eliminare i colli di bottiglia. Ha realizzato numerosi script e diverse automazioni per raccogliere ed elaborare i dati delle varie applicazioni, presentando poi i risultati nella forma di report destinati ai manager. Il sistema che John ha costruito è fondamentale per la società, e l’importanza del suo lavoro è stata ampiamente riconosciuta da tutti. L’azienda adesso è cresciuta. Ha acquisito un business nuovo, e come risultato i suoi sistemi informatici non sono più adeguati. Semplice replica di un sistema precedente? John è stato contattato dai vertici della compagnia per costruire un altro sistema. Gliene avevano chiesto uno “... proprio come il primo, ma questa volta per la vendita di ruote dentate invece che di ingranaggi”. John ha accettato l’incarico, ma si è reso subito conto che replicare semplicemente il sistema originale non sarebbe stato un compito così semplice. I suoi script erano infatti Hardcoded, contenevano cioè componenti specifici non modificabili di quel sistema. L’architettura del database che aveva realizzato era specificamente progettata per trattare ingranaggi. I nomi dei server e degli script erano codificati in ogni singolo script, attività e processo, e vi erano moltissime automazioni basate sul business degli ingranaggi diffuse in tutta l’infrastruttura aziendale. Tradurre anche un job semplice del database da ingranaggi a ruote dentate, avrebbe richiesto mesi di investigazione, ricodifica e test di regressione. John aveva di fronte un gran numero di applicazioni, e il risultato finale del suo lavoro avrebbe potuto non essere all’altezza del suo sistema precedente. Soluzione: centralizzare la gestione dei job La soluzione ideale sarebbe stato disporre di un sistema centrale di gestione dei job, all’interno del quale controllare tutti gli script, le attività e i processi aziendali. Questo avrebbe potuto diminuire molto i rischi dell’attività di John, fino ad annullarli. Si è già rilevato come un buon job sia ri-utilizzabile. In esso, le variabili vengono impiegate per astrarre elementi come i nomi dei server o degli script richiamati (nel nostro esempio, ruote dentate o ingranaggi), in modo che le pianificazioni possano venire ridefinite sulla base di eventuali nuove richieste, con il minimo di lavoro investigativo, ricodifica e test. Una buona soluzione di job scheduling prevede la possibilità di espansione del business, e di conseguenza l’aumento di servizi per soddisfare le esigenze dell’azienda. Caso 4: La raccolta dati è più di una semplice La Società D vende un prodotto di successo. Aveva iniziato in origine come una piccola azienda, ma nel corso degli anni si è ampliata ed ha incrementato il giro d’affari. Copyright @ ORSYP 2014 All Rights Reserved 14
WHITE PAPER: Soluzioni per l’automazione del job scheduling La crescita ha posto alcuni problemi, tra cui una proliferazione di applicazioni che in realtà solo pochi utilizzano all’interno dell’azienda, e situazioni di disordine nella gestione delle soluzioni informatiche, alcune delle quali erano state create per risolvere problemi specifici o rispondere a determinate esigenze. Crescita del business e applicazioni differenti La Società D è costituita da tante piccole realtà, con una moltitudine di applicazioni che non sono omogenee. Per esempio, un’applicazione che si occupa del budget potrebbe archiviare i propri dati in SQL, un’altra in Oracle, una terza invece in qualche linguaggio ormai obsoleto o conosciuto soltanto da pochi specialisti. Armonizzare tra loro queste applicazioni e integrare i dati è un’attività fondamentale per la Società. Molte aziende utilizzano differenti database e applicazioni di Business Intelligence (BI), come i Crystal Report. Queste soluzioni aggregano dati provenienti da diverse architetture, trasformandoli per esempio da un formato Oracle ad uno SQL. Gli strumenti di BI sono in grado di realizzare integrazioni di dati collegando diversi database. La Società D utilizza Crystal Report proprio per raccogliere i dati di bilancio delle varie unità di business. Soluzione: creare un flusso di lavoro automatizzato Una struttura aziendale complessa, come nel caso della Società del nostro esempio, è costituita normalmente da diverse unità di business, e ciò comporta la necessità di orchestrare i processi e sincronizzare i database per disporre di informazioni costantemente aggiornate sulla base delle quali prendere le decisioni. Le soluzioni di Business Intelligence sono spesso dotate di una vista unificata su piattaforme diverse, ma non offrono strumenti per unificare le operazioni tra i sistemi. Ciò di cui la Società D ha realmente bisogno è una pianificazione del sistema informatico aziendale per gestire al meglio i job e creare un flusso di lavoro automatizzato. Le operazioni per la raccolta dei dati possono essere più complesse di quanto si pensi, ma anche in questo caso un sistema di pianificazione delle elaborazioni costituisce la soluzione giusta per soddisfare le esigenze del business. Caso 5: Controllo del trasferimento dati nell’e-commerce Da quando ha iniziato l’attività di e-commerce, la Società E si è resa conto che le transazioni e la comunicazione on-line con i clienti generano grandi volumi di dati, ed è tutt’altro che semplice creare un sistema complessivo in grado di gestirli, ottenendo informazioni strategiche per guidare lo sviluppo dell’azienda. I dati grezzi si presentano in vari formati. La Società mette infatti a disposizione dei clienti servizi web per informazioni sui prodotti, con la possibilità di effettuare acquisti on-line. Formati diversi in contesti non strutturati La varietà dei formati di dati crea problemi quando si lavora in contesti non strutturati, in quanto spesso non è possibile integrare le informazioni tra sistemi diversi o all’interno dei flussi di elaborazione aziendali. La Società E aveva bisogno di un sistema informatico in grado di svolgere le operazioni richieste nel commercio elettronico, per esempio registrare gli ordini effettuati dai clienti, garantire la sicurezza dei dati e notificare agli utenti quando la transazione è andata a buon fine. Soluzione: piattaforma comune e automazione del flusso di lavoro Queste operazioni presuppongono una piattaforma comune per gestire i differenti formati di file. Una soluzione di job scheduling comprende il trasferimento dei file in un flusso di lavoro aziendale complessivo, in cui possono essere presenti, ad esempio, formati XML, SMTP, FTP e SFTP. Nelle soluzioni di e-commerce in particolare, deve inoltre essere garantita la sicurezza delle transazioni. Da qui l’ulteriore complessità di gestire anche protocolli come SSH, o di scambiare informazioni strutturate attraverso l’implementazione di Web Service tramite il protocollo SOAP. Copyright @ ORSYP 2014 All Rights Reserved 15
WHITE PAPER: Soluzioni per l’automazione del job scheduling La risposta più funzionale e sicura a questo insieme di esigenze è rappresentata, ancora una volta, dall’automazione delle elaborazioni, che costituisce un sistema di alto livello per gestire ed integrare i flussi di dati. Caso 6: Flussi di lavoro complessi e trigger per le elaborazioni Il sesto esempio ci riporta alla storia iniziale del progetto per la mia azienda. Ho cercato di spiegare come un processo di pianificazione fosse l’unico sistema per conseguire in modo rapido ed efficiente gli obiettivi di quel progetto. Lasciate che vi racconti ora, un po’ più in dettaglio, come si è sviluppata quella storia. Avevamo bisogno che i dati aziendali esterni, dopo essere stati ricevuti dal server FTP, fossero trasferiti al server SQL il più velocemente possibile, quasi in tempo reale. Difficoltà nell’integrazione dei dati L’ipotesi di realizzare ciò con il solo FTP aveva dato luogo ad un lavoro incredibilmente complicato, perché si doveva costruire una sessione di trasferimento dati sempre attiva. Questa idea è stata subito scartata in quanto, tra l’altro, non garantiva la sicurezza dei dati. Abbiamo quindi pensato di installare un tipo di agente, o meglio ancora di implementare una soluzione che in realtà non prevedesse alcun tipo di agente, la quale semplicemente rilevasse l’arrivo dei dati. Le informazioni potevano poi essere trasferite dal server FTP al database SQL. Questo era solo uno dei problemi, ma ne esistevano anche altri. I nostri sistemi SQL e Oracle dovevano infatti rimanere sincronizzati. Modifiche a valori specifici in uno dovevano essere replicati sull’altro praticamente in tempo reale. Tale sincronizzazione comportava il trasferimento di metadati con SAP. Anche una sola di queste esigenze poteva essere difficile da soddisfare per gli sviluppatori. Cercando di ottenere il massimo dalle risorse a disposizione, avevamo scelto di implementare un sistema che indirizzasse le necessità restando ad un livello di pianificazione alto. Soluzione: pianificazione e trigger per qualsiasi esigenza Ciò di cui avevamo bisogno erano i trigger (letteralmente “grilletti”). I trigger sono la base di una soluzione di pianificazione dei processi informatici, e ne esistono di diversi tipi. Il nostro progetto richiese una vasta gamma di essi. Ad esempio, il job FTP per gestire il flusso di dati verso SQL ha bisogno di un sistema basato su file, in grado di gestire le elaborazioni sul server FTP. Inoltre, erano necessari trigger innescati da un messaggio per integrare SQL con Oracle, consentendo alle due applicazioni di comunicare tra loro per effettuare la sincronizzazione dei dati. Trigger a evento sono invece necessari per gestire la comunicazione tra sistemi Oracle e SAP. Analogamente, servono trigger per il corretto funzionamento dell’Active Directory e dei sistemi che permettono l’accesso ai dati. Infine, il nostro progetto prevedeva “grilletti” a tempo per trasferire dati dal database SQL al mainframe UNIX. Avevamo poi bisogno di collegare gli eventi in un unico processo. Esistono trigger di concatenamento proprio per queste esigenze, i quali permettono di accelerare i processi e di mantenere una vista unica su tutto il sistema. Vedremo meglio questo tipo di meccanismo nel prossimo capitolo. Ai fini della scelta da parte vostra della migliore soluzione di pianificazione dei processi informatici, in base all’esperienza personale e ai risultati di quell’importante progetto che avevo realizzato per la mia azienda, posso consigliare di orientarsi verso il sistema che offre la più ricca suite di trigger, per soddisfare il maggior numero di esigenze che la vostra azienda potrebbe avere. Copyright @ ORSYP 2014 All Rights Reserved 16
Puoi anche leggere