Progettazione di un processo ETL basato sul contenuto con .NET e SFDC

4

Poiché la mia azienda compie la transizione verso l'utilizzo di SFDC come nostro principale sistema operativo, abbiamo riunito un paio di portali SFDC in cui possiamo pubblicare i documenti specifici dei clienti per essere visualizzati a piacere. Come tale, abbiamo avuto la necessità di implementare applicazioni pseudo-ETL in grado di estrarre metadati dai documenti che i nostri analisti generano internamente (la maggior parte sono formati PDF standard, XML o MS Office) e posizionati in rete " coda "cartelle. Da lì, le nostre applicazioni acquisiscono i documenti in coda e li caricano nella libreria di contenuti CRM di SFDC appropriata insieme ad alcuni pezzi selezionati di metadati. Ho utilizzato principalmente DbAmp per mediare le comunicazioni con SFDC (DbAmp è un provider di server collegato che consente di utilizzare le convenzioni SQL per interagire con i dati dell'organizzazione SFDC).

Sono riuscito a creare applicazioni [console] in C # che funzionano abbastanza bene e di solito sono strutturate in questo modo:

static void Main()
{
    // Load parameters from app.config.
    // Get documents from queue.
    var files = someInterface.GetFiles(someFilterOrRegexPattern);

    foreach (var file in files)
    {
        // Extract metadata from the file.
        // Validate some attributes of the file; add any validation errors to an in-memory          
        // structure (e.g. List<ValidationErrors>).
        if (isValid) 
        {
            var fileData = File.ReadAllBytes(file);
            // Upload using some wrapper for an ORM or DAL
            someInterface.Upload(fileData, meta.Param1, meta.Param2, ...);
        }
        else
        {
            // Bounce the file
        }
    }

    // Report any validation errors (via message bus or SMTP or some such).
}

E questo è praticamente tutto. Il più delle volte avvolgo tutte queste operazioni in una classe "Worker" che prende le interfacce necessarie come parametri del costruttore.

Questo approccio ha funzionato ragionevolmente bene, ma ho appena avuto questa sensazione nel mio intestino che c'è qualcosa di terribile in questo e vorrei un po 'di feedback. La scrittura di un processo ETL come app C # Console è una cattiva idea? Mi sto anche chiedendo se ci sono alcuni schemi di progettazione che sarebbero utili in questo scenario che sto chiaramente trascurando.

Grazie in anticipo!

    
posta Patrick 04.07.2012 - 22:13
fonte

1 risposta

1

Bene ... concentrandosi solo sugli aspetti pratici del problema ETL generale, senza troppi sforzi aggiuntivi è possibile separare la logica di supporto in uno o più assembly di riferimento e creare un semplice servizio Windows per chiamare nel proprio ETL elaborare in modo identico.

È banale configurare un'applicazione di servizio Windows per essere eseguibile anche tramite console (tramite un argomento della riga di comando) in modo da non perdere la possibilità di eseguirlo come console, se lo si desidera.

In cambio ottieni la possibilità di eseguire il processo ETL come servizio Windows; utilizzando un System.Threading.Timer o un meccanismo di pianificazione a scelta all'interno dell'oggetto servizio Windows offre una soluzione automatizzata / programmata che raramente richiede l'intervento manuale.

Se il tuo processo ETL funziona già come app per console, dovrebbe portarti da qualche ora a un paio di giorni (a seconda di quanto sei abile con i servizi di Windows e se vuoi abbellire la soluzione w) / extra campane e fischietti) per evolvere in un servizio di Windows e iniziare a testarlo.

Poiché la stessa logica ETL stessa è indipendentemente disponibile da questo modo di eseguirlo, puoi anche guidare la logica da altre applicazioni, come un flusso di lavoro o da una o più GUI.

Le app per console sono utili per gli utili strumenti di sviluppo "utility", un processo in batch, interfacce utente in stile linea di comando (una cosa rara di questi tempi), per ottenere qualcosa da zero o per giocare con una logica senza preoccuparsi sul cablaggio di una GUI e così via.

Ma i processi mission critical, ripetitivi o operativi meritano un meccanismo di esecuzione / interazione più robusto, secondo me.

Da una prospettiva "Patterns", sarebbero necessari più logica e contesto per fare una vera raccomandazione, ma da una prospettiva ETL generale il pattern Pipeline alias Tubi e filtri è spesso una considerazione chiave ... potresti già avere una versione semplice di essa impostata anche se non hai deliberatamente deciso di implementarla poiché è molto naturale a questo tipo di problema.

Se stai ETL facendo un sacco di dati, probabilmente vorrai prendere in considerazione la possibilità di suddividerlo in parti che puoi eseguire in parallelo sull'elaborazione ... ma questo porta a una discussione più ampia.

Spero che qualcosa in là aiuti ...

    
risposta data 06.11.2012 - 21:19
fonte

Leggi altre domande sui tag