JAVA与SAP

justforregister

最初由 sunkingpeng 发布
[B]以后ｓａｐ的方向是把ｊａｖａ整合到ｓａｐ的开发中，但是目前，说实话，ｓａｐ的ｊａｖａ开发部分做的并不是很好，我以前就是做ｊａｖａ的，后来做ａｂａｐ，希望ｓａｐ不要闭门造车，把ｊａｖａ已经成熟的东西直接买来用，不要自己去研究，费事还不好用。 [/B]

java有多成熟？abap就不成熟了？

sapbigcow

JAVA和ABAP的历史都超过10年了,算是很成熟的了.不过ABAP语言确实需要吸取JAVA的长处.

ssole

最初由 meiok1 发布
[B]比起Java开发工具来，SAP的开发工具即慢（开发效率低）又慢（执行速度慢）。Java在WEB和无线移动设备开发等方面的优势显而易见。将来用户在无线数据传输方面的需求巨大。如果用ABAP进行这样的开发实在是拿着耗子当马骑，太牵强了。必须要Java技术来客串一下。
    同样是WebDynpro开发，你用Developer Studio（eclipse）开发和用ABAP Webdynpro开发是截然不同的感觉，前者是开保时捷，后者是开拖拉机，这就是区别。
    好在SAP公司意识到自己衣服上的大窟窿（编程技术落后），打上NetWeaver这块大补丁。NetWeaver平台上，XI、Portal、WebDynpro等技术都挂上了先进技术的头衔，其实这些早就不是什么新鲜货。只不过是财大气粗的SAP对Webservice、企业门户、Web开发等技术进行了包装而已。就连概念比较模糊的SOA都被包装成为E-SOA，加上E好像比不加E时髦。
    传统的ABAP技术，是衣服。Java技术是补丁。补丁毕竟是补丁，不能完全代替衣服。
说不定哪一天补丁会打满整件衣服，成了百家衣，但补丁毕竟是补丁，不会完全替代衣服。这就是ABAP和JAVA [/B]

怎么被你说的这么难听啊, 虽然有些,我也感觉差不多.
但是还没这么差吧. 执行效率都差不多的. ABAP和JAVA就谁都别说谁了.都不是太好. 否则银行的那些支付程序, 早就想换了.

ABAP比JAVA早,
在没有JAVA的虚拟机器以前,ABAP不就是在虚拟机器上跑的嘛

ABAP也在进步. 都在进化,
短时间内, 还看不到SAP系统要被新语言所取代的趋势,
现在已经发布的所有的产品大多是基于ABAP做的,
好象不太可能会用JAVA写.

客户项目中, 我现在用的也有限, JAVA也就只能写过一些终端的UI, 或者调用一些基础的逻辑然后包成一个SERVICE.

AIS
SAP即将要发布的新的产品AIS(产品代号), 好象用的非常多的JAVA(可以说是基于JAVA吧!). 所以WebDynpro for JAVA是开发AIS的最主要的UI策略,这是SAP CEO说的.

BANKING
新的CoreBanking 也用WebDynpro for JAVA来做了部分UI了,虽然有SAP GUI,客户买
你的BANKING系统, 好象SAP GUI不太会去用的. 顶多做做后台的处理.前台用.NET
来开发的. 用RFC/BAPI/ESOA来调调.

老的ERP
大型企业, 还是就用WEBDYNPRO FOR ABAP好了, 本地调用, 本地CALL, ABAP代码多好.
很多程序可以重复使用. 就别在ERP上搞WebDynpro for JAVA了.
反正SOA也支持的.
然后ERP也为它全部的模块发布了新的WEB SERVICE包包,企业需要的化, 就自己下载,
安装, 以前用BAPI,现在可以用ESOA了, 慢慢的会把很多的逻辑包成ESOA方式的.

CRM
压根就没有WebDynpro 也快逐渐抛弃老的ICWC了, 而是学了WebDynpro一些概念
还是新的CRM 2006S的UI名字还叫CRM WEB UI. 也从来不需要PORTAL.也挺好的.
虽然还是BSP写的,WEB的构造变了点.

SCM,SRM
好象用WebDynpro for abap把很多UI都WEB化了, 当然还用了一些些的BSP/JAVA.

就知道这么一点

justforregister

最初由 ssole 发布
[B]

怎么被你说的这么难听啊, 虽然有些,我也感觉差不多.
但是还没这么差吧. 执行效率都差不多的. ABAP和JAVA就谁都别说谁了.都不是太好. 否则银行的那些支付程序, 早就想换了.

ABAP比JAVA早,
在没有JAVA的虚拟机器以前,ABAP不就是在虚拟机器上跑的嘛

ABAP也在进步. 都在进化,
短时间内, 还看不到SAP系统要被新语言所取代的趋势,
现在已经发布的所有的产品大多是基于ABAP做的,
好象不太可能会用JAVA写.

客户项目中, 我现在用的也有限, JAVA也就只能写过一些终端的UI, 或者调用一些基础的逻辑然后包成一个SERVICE.

AIS
SAP即将要发布的新的产品AIS(产品代号), 好象用的非常多的JAVA(可以说是基于JAVA吧!). 所以WebDynpro for JAVA是开发AIS的最主要的UI策略,这是SAP CEO说的.

BANKING
新的CoreBanking 也用WebDynpro for JAVA来做了部分UI了,虽然有SAP GUI,客户买
你的BANKING系统, 好象SAP GUI不太会去用的. 顶多做做后台的处理.前台用.NET
来开发的. 用RFC/BAPI/ESOA来调调.

老的ERP
大型企业, 还是就用WEBDYNPRO FOR ABAP好了, 本地调用, 本地CALL, ABAP代码多好.
很多程序可以重复使用. 就别在ERP上搞WebDynpro for JAVA了.
反正SOA也支持的.
然后ERP也为它全部的模块发布了新的WEB SERVICE包包,企业需要的化, 就自己下载,
安装, 以前用BAPI,现在可以用ESOA了, 慢慢的会把很多的逻辑包成ESOA方式的.

CRM
压根就没有WebDynpro 也快逐渐抛弃老的ICWC了, 而是学了WebDynpro一些概念
还是新的CRM 2006S的UI名字还叫CRM WEB UI. 也从来不需要PORTAL.也挺好的.
虽然还是BSP写的,WEB的构造变了点.

SCM,SRM
好象用WebDynpro for abap把很多UI都WEB化了, 当然还用了一些些的BSP/JAVA.

就知道这么一点 [/B]

不错，
webdynpro这东西还只是trial，成功的话， 以后都会用他。
还有那个代号是A1S 不是AIS。
java在sap里就目前来看， 还只能作边角料的活。主角还是abap。

againgan

我認為ABAP比較還是一直以來是SAP主要開發工具，不過未來我還是看好Java。

justforregister

原帖由 againgan 于 2008-6-24 15:50 发表
我認為ABAP比較還是一直以來是SAP主要開發工具，不過未來我還是看好Java。

不太可能， 就像我们中国人说中文， 虽然英文很重要， 但是让中国人全转英文是不可能的

Marshall605

我觉得现在会说java取代abap的，基本上都是以自己的主观意识来做臆测。我觉得java完全不可能成为sap的主流，假使有这个趋势，sap公司也会出面阻止。毕竟怎么说呢，这是一个很大的利益关系。
    开发出java的是sun公司，但是你敢说sun公司在java方面有绝对的权威？sun公司能够说今天java往哪里发展，java就会往哪里发展？但是靠着sap的系统相对封闭，sap却可以做到。就好像现在，出了个for java。我们就可以用java来写了。而这种在行业内的领导力换谁都不会轻易放弃。
    我才刚刚开始学abap和java。就初学者的角度来说，abap是土的不行，等于号前少个空格都会报错。但是觉得要说开发效率来说，感觉在习惯了之后，abap我想不会java慢多少。有内表的abap在商业数据处理方面不会逊于java。当然这东西java可以写个类。但是毕竟不是原装的。
    最后，我还是同意楼上一个人的观点。其实作为一个程序员，关键的是思想和逻辑能力。语言只是我们手中的画笔而已。画出怎么样的画，画笔不是决定性因素。

Winter-lu

要是我,也會這麼做,用abap和Java都可以,但是不能不走Java(這個東西自身特點決定生存空間),也不能馬上丟掉ABap(要考慮現有用戶),並存同時過渡,我會讓你有意識的往我希望的方向過渡.目前SAP是這樣做的吧.

justforregister

sap的下一代产品还是用abap写的， 各位puber有生之年估计是没机会看到sap转java了

开心老猪

原帖由 meiok1 于 2007-4-13 23:17 发表
比起Java开发工具来，SAP的开发工具即慢（开发效率低）又慢（执行速度慢）。Java在WEB和无线移动设备开发等方面的优势显而易见。将来用户在无线数据传输方面的需求巨大。如果用ABAP进行这样的开发实在是拿着耗子当马骑，太牵强了。必须要Java技术来客串一下。
    同样是WebDynpro开发，你用Developer Studio（eclipse）开发和用ABAP Webdynpro开发是截然不同的感觉，前者是开保时捷，后者是开拖拉机，这就是区别。
    好在SAP公司意识到自己衣服上的大窟窿（编程技术落后），打上NetWeaver这块大补丁。NetWeaver平台上，XI、Portal、WebDynpro等技术都挂上了先进技术的头衔，其实这些早就不是什么新鲜货。只不过是财大气粗的SAP对Webservice、企业门户、Web开发等技术进行了包装而已。就连概念比较模糊的SOA都被包装成为E-SOA，加上E好像比不加E时髦。
    传统的ABAP技术，是衣服。Java技术是补丁。补丁毕竟是补丁，不能完全代替衣服。
说不定哪一天补丁会打满整件衣服，成了百家衣，但补丁毕竟是补丁，不会完全替代衣服。这就是ABAP和JAVA

呵呵，看来这位老兄对SAP颇有深恶痛绝之感。

以老猪的拙见，说到Java和ABAP, 本来是非常类似的架构，都是构筑在虚拟机技术之上，只不过Java的面向领域更加通用化，而ABAP更重在商务事务处理。虽说同出一门，但对于晚出现5年左右的Java, ABAP算得上大哥。

所以Java虚拟机在通用化程度略胜一筹，无论是服务器端、客户端、包括终端设备端、都有相应的JVM,  但也更偏重在架构的底层，可以依照编程者的想法自由发挥；

而ABAP则在企业应用等平台领域更加严谨，且只部署在服务器端。但涵盖用户管理，逻辑数据库，变更管理，监控体系，审计功能，工作流引擎等等。。。就拿大i家熟悉的Change Request管理来说，ABAP引擎当中各版本从数据定义，到源代码都存放在数据库当中，而Java则直接存放于相应文件系统中。对于个人编程者或小型开发项目而言，可能会觉得严谨的管理制度繁琐，但对于可能出现的数百人，甚至上千人的协同项目而言。完善的TMS管理有着非同寻常的意义。

对于Java技术的发展， SAP并非从NetWeaver开始，而是在WAS，也就是平时大家熟悉的R/3 Enterprise 4.7开始就大范围使用了。而NetWeaver架构的出现，是先是从企业应用的角度，全方位地针对使用者、信息、流程等集成问题提供了一个相对完整的解决方案。继而在此基础上完善了eSOA体系的实质 （之所以说实质，是在此之前SOA更多停留在webService, UDDI, SOAP等技术实现机制层面，而非企业应用整体解决放案产品层面）   另外，这里的“e”好像并不是时髦，反而是往往与时髦背道而驰的企业应用中的Enterprise

WebDynpro，其核心是在MVC架构中，有效融合MV两层机制，方便实现UI曾展现和控制的机制。由其使用在Java Engine和ABAB Engine的不同，而有了JavaWebDynpro和AbapWebDynpro的区别，对于解决同一层面问题的两种不同的技术适用场合不同，技术手段不同，并不具有相互替代性。 举个例子来说，在原有R/3业务模块工作流当中希望使用Adobe Interactive Form的时候，用WebDynpro就极其方便。

此外，就目前还没有听到过有任何要用Java取代ABAP的计划，或者在SAP内部，也看不到任何这方面的必要性。对于这两种技术，会在较长的一段时间之内并存。可能的区分是：ABAP更多使用在实现企业核心业务功能，类似财务，后勤，人事等事务处理领域；而Java等多使用在UI, 集成等领域。

让SAP穿一件满是补丁的百家衣？         如果不是拿人参当萝卜干卖了，恐怕就只能是Larry Ellison在痴人说梦了吧。。。。。