¿Tiene sentido un sistema .net/sap mixto?

Question

Esta podría ser una pregunta un poco vaga, pero la vida real es así.

Nuestra empresa está implementando el sistema SAP. Sé que ahora hacen servicios web para que podamos lanzar simultáneamente .NET todo lo que sabemos que podemos hacer en C#.

¿Cuáles son las dificultades en el camino de la integración de SAP - .NET? Entiendo que la lógica de SAP es bastante diferente de la programación "estándar", pero espero separar la parte de "negocios" de la parte de "presentación", que se escribirá en ASP.NET.

Answer 1

Si sus aplicaciones no requieren la integración de SAP Portal y sus clientes no piden una apariencia tipo SAP, entonces usted es libre de usar la capa de presentación que desee.

No estoy de acuerdo con la postura de que debe usar las herramientas de sap cuando elige realizar una integración de SAP. Productos como NWDI o NWDS antiguo son un claro dolor de cabeza (no voy a profundizar en eso aquí, es una larga historia), capacitar a la gente para aprender Webdynpro es, en mi opinión, no vale la pena el dinero si no eres un integrador de savia 100% dedicado.

Answer 2

No lo luche. Si está implementando SAP, simplemente implemente SAP. Está casi garantizado que no valdrá la pena luchar contra él.

SAP tiene herramientas para manejar la presentación si no le gusta la GUI (BSP, WDJ, WDA). No trataría de implementar una interfaz de terceros a menos que REALMENTE REALMENTE deba hacerlo.

Answer 3

Algunos consejos generales.

• Me parece que usted está buscando un "camino dorado" o algo así. Olvídalo. Nada en sapland es fácil, directo o, bueno, normal. Hay obstáculos y escollos en todas las direcciones. Pero no te desesperes. Después de que el dolor se asienta, la savia hace que su empresa (lo que sea) sea increíblemente bien.
• Para los usuarios de savia de núcleo duro (usuarios que manejan finanzas, horas, inventario y demás) tendrás que ir con lo que ofrece sap. La GUI será terrible, pero las personas son increíblemente adaptables. Y si no tienen otras opciones, les encantará lo que la savia tiene para ofrecer.
• Para usuarios ocasionales (informe de gastos, por ejemplo) hacerlo en lo que ofrece sap como GUI (sapgui web o de escritorio) es un desperdicio de recursos. Los usuarios encontrarán una manera innovadora de evitar esas aplicaciones. So.net es el camino a seguir. Te encontrarás con muchos problemas. Pero recuerda que la otra opción es peor.

respuesta al comentario: En primer lugar no creo que los informes no se deben hacer en la savia. Los informes son feos por naturaleza y la savia se destaca en ellos. Estaba pensando en pequeñas aplicaciones que no son el trabajo principal de los usuarios. Cosa como informar gastos, la aprobación de la solicitud de compra por parte de la gerencia, etc. Acerca de dónde puede encontrar material en dichas barricadas. No puedes. Tienes que encontrarlos primero con tu cabeza.

Answer 4

pensar bien de las razones detrás de usar .NET:

• no sólo tiene que utilizar .NET porque usted sabe que puede hacerlo eso no es una buena razón, pero si hay una razón válida para los negocios usando .NET luego adelante
• Sea consistente. Defina cuándo la capa de presentación debe ser .NET y cuándo no es apropiada.
• No intente "burlar" la funcionalidad estándar de SAP forzándola a comportarse de una manera diferente a lo que debe. (No estoy diciendo que no personalice; estoy diciendo que use las opciones de SAP preffered como Enhancements, User Exits, etc. obtendrá un mejor producto y mejor soporte SAP. No puede implementar SAP sin intentar comprender la oferta completamente)
• No hay "solo una regla" que necesite para comprender las necesidades de sus usuarios/clientes y simplemente porque use .NET para un sitio web orientado al cliente no significa que no pueda usar objetos comerciales para la administración informes o una simple cuadrícula ALV para la mayor parte de sus informes
• WEB Dynpro no es tan difícil de aprender para un desarrollador ABAP y si tiene que capacitar a desarrolladores fuera del espacio SAP WEB Dynpro será el menos aprendiendo curva. La lógica empresarial de SAP es mucho más difícil y la forma de reutilizar el estándar SAP de una manera compatible sin romper el núcleo es más un desafío que aprender el conjunto de herramientas ABAP.

Answer 5

Soy desarrollador de SAP ABAP y Microsoft.NET. Trabajo para una empresa que crea software utilizando SAP y otras plataformas, como Microsoft.NET, Java y RoR.

Dado que su empresa está implementando SAP, debe obtener el backend de ECC 6.0, que puede usar RFC o servicios web.

SAP tiene una API estándar conocida como Business API (también conocida como BAPI). Puedes probarlos en la transacción BAPI.

Un buen ejemplo es este: BAPI_USER_GET_DETAIL.

Este BAPI es responsable de devolver información sobre cualquier usuario de SAP. El BAPI solo requiere un parámetro de entrada único, llamado USERNAME, y devuelve diferentes estructuras de datos con información sobre el usuario, como el correo electrónico, nombre y apellido, perfiles de usuario, etc.

ABAP interior, una plantilla para llamar este BAPI debe ser algo como esto:

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 =. 

Ahora, cada BAPI es también RFC (Remote Function Call) habilitado. Esto significa que, si implementa la API de SAP RFC dentro de su aplicación, puede llamar a cualquier BAPI u otra función dentro de SAP configurada como habilitada para RFC.

En versiones anteriores, puede usar la API de SAP RFC estándar, o usar los conectores de SAP Wizard, como SAP .NET Connector o SAP Java Connector.

En las versiones más recientes, SAP ha adjuntado un servidor web a su servidor de aplicaciones ABAP, para ejecutar servicios tales como ITS, BSP y WebDynpro para ABAP. Al usar este servidor web, puede publicar cualquier RFC como un servicio web.

Pero, tomado de mi experiencia diaria, el rendimiento de SAP R/3 no es tan bueno. Una simple llamada RFC a una función que suma dos números y devuelve el resultado puede tomar de 1 a 5 segundos, dependiendo de la disponibilidad del servidor.

Esto sucede principalmente debido a los muchos niveles de abstracción que se producen cuando está utilizando SAP .NET Connector o WebServices.

Por lo tanto, si desea que su sistema esté disponible para transacciones diarias (como crear 5.000 clientes diariamente desde su aplicación de comercio electrónico, o hacer aproximadamente 40.000 ventas en línea), le recomiendo usar Java Connector o implementar la API de RFC por su cuenta.

De lo contrario, si su aplicación será utilizada internamente por menos personas, le recomiendo que utilice SAP .NET Connector o WebServices, simplemente porque están completamente orientados a GTD.

Espero que esto ayude!

(por favor, añadir el prefijo http: // a los siguientes enlaces, porque yo no tengo la reputación suficiente para publicar enlaces :()

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

SAP .NET conector: 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

Creación de servicios web utilizando ABAP: wiki.sdn.sap.com/wiki/display/stage/Service+Enabling+in+ABAP

Answer 6

He estado involucrado en una serie de implementaciones de .NET/SAP. Por un lado, recomiendo no usar .NET en lugar de simplemente escribir lo que desea en ABAP, pero, por otro lado, se puede hacer que funcione razonablemente bien. Como mencionamos anteriormente, la sobrecarga de los servicios web puede ser alta para transacciones pequeñas, así que intente configurar las cosas de manera que se transfiera una buena cantidad de datos a la vez (es decir, una pantalla completa). Hacer eso también significa que SAP puede procesar una transacción completa o más internamente, en lugar de pasar pequeñas cantidades de material a la vez y tener que manejar el estado. La lógica comercial debe implementarse dentro de SAP, con la parte .NET solo manejando la presentación/intercambio de datos.

Resumiré lo que se dijo sobre la interfaz de Gastos. La mayoría de las personas lo hace externamente con el software de otro proveedor, pero no tiene que usar material sofisticado de .NET para importar datos de gastos, solo tiene un trabajo por lotes simple que lo importa una vez al día. A veces, la forma más simple es la mejor.

Answer 7

En mi empresa estamos en la misma situación. Estamos llevando a cabo proyectos de integración con SAP utilizando .NET

Puede evitar los servicios web ejecutando funciones BAPI directamente desde .NET. Hoy aprendí que las funciones estándar de RFC también se pueden exponer como funciones BAPI.

estamos utilizando ERP Connect del software theobald para ejecutar funciones de bapi/RFC directamente y como no se menciona en esta discusión, pensé que podría beneficiarse de saberlo.

No es gratis, pero creo que hará la vida de los desarrolladores mucho más fácil.

Tenga en cuenta que no estoy afiliado de ninguna manera con el software theobald.