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
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 10WHITE 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 11WHITE 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 12WHITE 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 13WHITE 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 14WHITE 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 15WHITE 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 16Puoi anche leggere
