Un sistema misto .net/sap ha senso?

Question

Questa potrebbe essere una domanda un po 'vaga, ma la vita reale è così.

La nostra azienda sta implementando il sistema SAP. So che ora fanno i servizi Web in modo da poter distribuire simultaneamente la cosa .NET per tutto ciò che sappiamo che possiamo fare in C#.

Quali sono le insidie ​​lungo il percorso di integrazione di SAP - .NET? Capisco che la logica di SAP è molto diversa dalla programmazione "standard", ma spero di separare la parte "business" dalla parte "presentation", da scrivere in ASP.NET.

Answer 1

Se le tue app non richiedono l'integrazione di SAP Portal e i tuoi clienti non chiedono un aspetto simile a SAP, allora sei libero di usare qualsiasi livello di presentazione che ti piace.

Non sono d'accordo con la posizione secondo cui è necessario utilizzare gli strumenti sap quando si sceglie di eseguire un'integrazione SAP. Prodotti come NWDI o vecchi NWDS sono un chiaro mal di testa (non sto per approfondire qui, è una lunga storia), addestrando le persone ad imparare Webdynpro è secondo me non vale la pena se non si è un integratore di sap dedicato al 100%.

Answer 2

Non combatterlo. Se stai implementando SAP, implementa semplicemente SAP. È quasi garantito che non vale la pena di combatterlo.

SAP ha strumenti per gestire la presentazione se non ti piace la GUI (BSP, WDJ, WDA). Non proverei a implementare un front-end di terze parti a meno che non si debba davvero REALMENTE.

Answer 3

Pochi consigli generali.

• Mi sembra che tu stia cercando un "percorso d'oro" o qualcosa del genere. Dimenticalo. Niente in sapland è facile, diretto o, beh, normale. Ci sono blocchi stradali e insidie ​​in ogni direzione. Ma non disperare. Dopo che il dolore si è calmato, la linfa fa incredibilmente bene la sua impresa (qualunque cosa sia).
• Per gli utenti di hard-core sap (utenti che gestiscono la finanza, l'hr, l'inventario e così via), dovrete andare con ciò che sap offre. La gui sarà terribile, ma le persone sono straordinariamente adattabili. E se non hanno altre opzioni che cresceranno ad amare ciò che linfa ha da offrire.
• Per gli utenti occasionali (rapporto spese, ad esempio) farlo in quello che sap offre come gui (web o desktop sapgui) è uno spreco di risorse. Gli utenti troveranno un modo innovativo per evitare tali applicazioni. So.net è la strada da percorrere. Incontrerai molti problemi. Ma ricorda che l'altra opzione è peggiore.

risposta al commento: Prima di tutto non credo che le relazioni non dovrebbe essere fatto in SAP. I resoconti sono di natura brutta e sono eccellenti in loro. Stavo pensando a piccole applicazioni che non sono il lavoro principale degli utenti. Cose come le spese di segnalazione, la gestione che approva la richiesta di acquisto e così via. Informazioni su dove trovare materiale sui suddetti posti di blocco. Non puoi Devi prima trovarli con la testa.

Answer 4

pensare bene dei motivi dietro utilizzando .NET:

• Non basta usare .NET perché sai che puoi farlo che non è una buona ragione, ma se c'è un motivo valido per affari utilizzando .NET quindi vai per questo
• Sii coerente. Definisci quando il livello di presentazione deve essere .NET e quando non è appropriato.
• Non tentare di "mascherare" le funzionalità standard SAP forzandolo a comportarsi in modo diverso rispetto al suo scopo. (Non sto dicendo di non personalizzare - sto dicendo che uso le opzioni preffered di SAP come Enhancements, user Exits ecc. Otterrai un prodotto migliore e un migliore supporto SAP. Non puoi implementare SAP senza tentare di capire l'offerta completamente)
• Non c'è "una sola regola" è necessario comprendere le esigenze dei propri utenti/clienti e solo perché si utilizza .NET per un sito Web rivolto al cliente non significa che non è possibile utilizzare gli oggetti di business per la gestione reporting o una semplice griglia ALV
• WEB Dynpro non è così difficile da imparare per uno sviluppatore ABAP e se devi addestrare gli sviluppatori al di fuori dello spazio SAP WEB Dynpro sarà il minimo di apprendimento curva. La logica di business SAP è molto più difficile e come riutilizzare lo standard SAP in modo supportato senza interrompere il core è più una sfida che imparare il toolset ABAP.

Answer 5

Sono uno sviluppatore SAP ABAP e Microsoft.NET. Lavoro per un'azienda che crea software utilizzando SAP e altre piattaforme, come Microsoft.NET, Java e RoR.

Dal momento che la società sta implementando SAP, è necessario ottenere il back-end ECC 6.0, che può utilizzare RFC o Webservices.

SAP ha un'API standard nota come Business API (ovvero BAPI). Puoi provarli alla transazione BAPI.

Un buon esempio è questo: BAPI_USER_GET_DETAIL.

Questo BAPI è responsabile della restituzione di informazioni su qualsiasi utente SAP. BAPI richiede solo un singolo parametro di input, denominato USERNAME, e restituisce diverse strutture di dati con informazioni sull'utente, come e-mail, Nome e cognome, profili utente, ecc.

All'interno di ABAP, un modello per la chiamata questo BAPI dovrebbe essere qualcosa di simile:

CALL FUNCTION 'BAPI_USER_GET_DETAIL' 
EXPORTING 
USERNAME = sy-UNAME 
* IMPORTING 
* LOGONDATA = 
* DEFAULTS = 
ADDRESS = L_IT_RETURN1 
* COMPANY = 
* SNC = 
* REF_USER = 
* ALIAS = 
* UCLASS = 
* LASTMODIFIED = 
* ISLOCKED = 
TABLES 
* PARAMETER = 
* PROFILES = 
* ACTIVITYGROUPS = 
RETURN = L_IT_RETURN 
ADDTEL = i_Tel 
* ADDFAX = 
* ADDTTX = 
* ADDTLX = 
* ADDSMTP = 
* ADDRML = 
* ADDX400 = 
* ADDRFC = 
* ADDPRT = 
* ADDSSF = 
* ADDURI = 
* ADDPAG = 
* ADDCOMREM = 
* PARAMETER1 = 
* GROUPS = 
* UCLASSSYS = 
* EXTIDHEAD = 
* EXTIDPART = 
* SYSTEMS =. 

Ora, ogni BAPI è anche RFC (Remote Function Call) abilitato. Ciò significa che, se si implementa l'API RFC SAP all'interno dell'applicazione, è possibile chiamare qualsiasi BAPI o altra funzione all'interno di SAP configurata come RFC abilitata.

Nelle versioni precedenti, è possibile utilizzare l'API RFC standard SAP o utilizzare i connettori SAP Wizard, come SAP .NET Connector o SAP Java Connector.

Nelle versioni più recenti, SAP ha collegato un server Web al proprio ABAP Application Server, al fine di eseguire servizi quali ITS, BSP e WebDynpro per ABAP. Utilizzando questo server Web, è possibile pubblicare qualsiasi RFC come servizio Web.

Ma, preso dalla mia esperienza quotidiana, le prestazioni di SAP R/3 non sono così buone. Una semplice chiamata RFC a una funzione che somma due numeri e restituisce il risultato può richiedere da 1 a 5 secondi, a seconda della disponibilità del server.

Ciò accade principalmente a causa dei numerosi livelli di astrazione che si verificano durante l'utilizzo di SAP .NET Connector o WebServices.

Quindi, se si desidera che il sistema sia disponibile per le transazioni giornaliere (come la creazione di 5.000 clienti ogni giorno dalla propria applicazione di e-commerce o circa 40.000 vendite online) consiglio vivamente di utilizzare Java Connector o di implementare l'API RFC da solo.

In caso contrario, se la tua app verrà utilizzata internamente da un minor numero di persone, ti consiglio di utilizzare SAP .NET Connector o WebServices, solo perché sono completamente orientati alla GTD.

Spero che questo aiuti!

(per favore, aggiungere il prefisso http: // per I link qui sotto, perché io non ho abbastanza reputazione di postare link :()

L'API RFC: help.sap.com/printdocu/core /Print46c/EN/data/pdf/BCFESDE4/BCFESDE4.pdf

SAP .NET Connector: help.sap.com/saphelp_nw04/Helpdata/EN/e9/23c80d66d08c4c8c044a3ea11ca90f/content.htm

SAP Java Connector: help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5c6a85b11d6b28500508b5d5211/content.htm

Creazione di servizi Web tramite ABAP: wiki.sdn.sap.com/wiki/display/stage/Service+Enabling+in+ABAP

Answer 6

Sono stato coinvolto in una serie di implementazioni .NET/SAP. Da un lato, mi raccomando di non usare .NET invece di scrivere quello che vuoi in ABAP, ma d'altro canto, può essere fatto funzionare ragionevolmente bene. Come qualcuno menzionato sopra, il sovraccarico per i servizi Web può essere elevato per le transazioni di piccole dimensioni, quindi cerca di impostare le cose in modo che una buona quantità di dati sia passata in una volta (cioè un intero schermo pieno). Ciò significa anche che SAP può elaborare un'intera transazione o più internamente, invece di passare piccole quantità di materiale alla volta e dover gestire lo stato. La logica aziendale dovrebbe essere implementata all'interno di SAP, con la parte .NET che gestisce solo la presentazione/lo scambio di dati.

Risponderò a ciò che è stato detto sull'interfaccia Spese. Molti lo fanno esternamente con il software di un altro fornitore, ma non è necessario utilizzare roba .NET in tempo reale di fantasia per importare dati di spesa, basta un semplice lavoro batch che lo importa una volta al giorno. A volte il modo più semplice è il migliore.

Answer 7

Nella mia azienda siamo nella stessa situazione. Stiamo eseguendo progetti di integrazione con SAP utilizzando .NET

È possibile evitare i servizi Web eseguendo le funzioni BAPI direttamente da .NET. Oggi ho imparato che le funzioni RFC standard possono essere esposte anche come funzioni BAPI.

stiamo usando ERP Connect dal software theobald per eseguire direttamente le funzioni bapi/RFC e poiché non menzionato in questa discussione, ho pensato che potreste trarne beneficio.

Non è gratuito, ma penso che renderà la vita degli sviluppatori molto più semplice.

Si prega di notare che non sono affiliato in alcun modo con il software theobald.