Esportare i dati da SAP a SQL Server

Question

Ho un'applicazione che utilizza SQL Server 2008 per archiviare dati che devono alimentare un gruppo di informazioni finanziarie da SAP (che in questa azienda utilizza Oracle 11 come back-end).

Ho chiesto ai ragazzi SAP l'accesso per leggere i tavoli, hanno detto che non c'era modo. Ho chiesto loro di connettersi direttamente al mio database per riempire i miei tavoli, hanno detto che non c'era modo. (Ho un feed da un database Oracle, un'altra applicazione diversa da SAP, utilizzando il gateway trasparente senza problemi, ecco perché è stato chiesto)

Dicono che l'unico modo per interagire con SAP è attraverso l'uso del Web Servizi. Ma a causa dell'enorme quantità di dati, non penso che sia il percorso.

Qualcuno ha esperienza nella creazione di un'interfaccia tra SAP e un server SQL?

Ho intenzione di estendere la mia spiegazione. La mia attuale applicazione è già alimentata da altre tre applicazioni (questa è una grande impresa) che vanno tutte alle stesse tabelle dove ricevo i dati per elaborare ulteriormente. Tutte le altre applicazioni (1 Oracle, 2 SQL Server) eseguono un aggiornamento diretto o stored procedure che salvano i dati. Queste altre 3 applicazioni sono gestite da squadre diverse senza alcuna relazione l'una con l'altra. Tutti si sono lamentati all'inizio, ma alla fine hanno accettato di esportare i propri dati su questa applicazione.

Quindi, l'ideale sarebbe convincere i ragazzi SAP a fare lo stesso: aprire una connessione a SQL Server ed eseguire alcuni inserimenti o eseguire stored procedure.

Answer 1

La domanda di base è: push o pull? È possibile disporre di una sorta di configurazione che consente al sistema SAP R/3 di esportare periodicamente alcuni dati che vengono successivamente acquisiti, oppure è possibile che un sistema esterno raggiunga e acquisisca i dati. Per quanto riguarda "l'unica necessità di interagire con SAP è attraverso l'uso di servizi Web" - tecnicamente parlando, è più vicino alle feci del partner della mucca che otterrete. Potrebbero esserci problemi non tecnici - politiche strane o amministratori di sistema non voluti - ma concentriamoci sui dettagli.

Per quanto riguarda una soluzione "push", è possibile configurare uno dei report esistenti da eseguire periodicamente e salvare l'output in un file o spedirlo da qualche parte. Questo è relativamente facile da fare, ma richiede che ci siano rapporti che ti danno i dati che desideri. Se non ci sono, annota le specifiche e programmale o chiedi a qualcuno di programmarle. Non è magia, solo un altro linguaggio di programmazione.

Se si vuole tirare, si può andare direttamente al database, ma lo sconsiglio vivamente. Non appena raggiungi il tuo primo cluster table, avrai raggiunto un punto morto. Se stai pensando a grandi quantità di dati, il modo migliore per estrarli sarebbe probabilmente quello di stabilire una connessione RFC (protocollo proprietario, vedere molte altre domande qui) e utilizzare un BAPI se ne esiste uno (è un'interfaccia di programmazione che è rilasciato per uso ufficiale e gestito da SAP) o utilizzare RFC_READ_TABLE per accedere ai dati. Si noti che quest'ultimo non è utilizzabile per tutte le tabelle, dipende dalla struttura della tabella (dimensione totale e tipi di campo). I servizi Web aggiungono solo un altro livello di codifica e uno rumoroso, non molto adatto per i processi ETL ad alto volume.

Answer 2

Ho fatto questo alcune volte nel corso degli anni e ho ricevuto sostanzialmente la stessa risposta dai team SAP che avete ottenuto. In quasi tutti i casi, la soluzione si è trasformata in "report" di file flat generati da SAP caricati in SQL Server tramite pacchetti SSIS. Il trucco è assicurarsi che i report siano progettati correttamente. Ho visto che i team SAP includono filtri "predefiniti" nella creazione di questi rapporti che non sono stati menzionati fino a quando il processo non era in diretta e mancavano i dati. In bocca al lupo.

Answer 3

Eseguiamo SQL anziché Oracle e abbiamo riscontrato un problema simile. Ci è stato detto che l'accesso diretto al livello DB di un sistema SAP annullerebbe la garanzia. Quindi abbiamo chiesto direttamente a SAP: sono a posto per fare selezioni sul DB a patto che non si aggiorni, non si inserisca o si elimini senza passare attraverso il livello App. Se si aggiorna, si inserisce o si cancella al di fuori del livello dell'app, si annulla la garanzia, pertanto non è un avviamento. Puoi fare in modo che il tuo team SAP apra un messaggio OSS se vorrebbe la stessa risposta.

Detto questo, se si tratta di un'interfaccia continua piuttosto che di un carico di dati una tantum, vorrei semplicemente che qualcuno ti costruisse un RFC, un servizio Web o un estratto in corso per prelevare i dati dall'app.

Answer 4

Come si saprà per tale interfaccia di applicazione, l'opzione migliore dipende da una serie di fattori come il volume di dati, la modalità di interfaccia desiderata in tempo reale rispetto al batch, sincrono vs asincrono. Se il volume dei dati è ampio e non è necessario disporre di aggiornamenti in tempo reale per l'applicazione, l'esecuzione di un report sul lato SAP e la generazione di un file di dati per il caricamento nella propria applicazione dovrebbero essere un'opzione accettabile. Per gli aggiornamenti in tempo reale possono essere utilizzati IDoc (più file di dati). In caso contrario, è possibile utilizzare le API SAP standard (BAPI) per estrarre da SAP le informazioni necessarie. Puoi anche fare in modo che i tipi SAP creino un RFC personalizzato per la funzione RFC_READ_TABLE e utilizzi la query SQL like per ottenere i dati da SAP.

È possibile aggiornare il database dell'applicazione direttamente utilizzando SQL nativo nel programma ABAP sul lato SAP. L'ho fatto per il server MS-SQL e non vedo alcuna limitazione per usarlo anche per Oracle.