首先庆祝我司继续领跑，朋友圈号称杀疯了~也欢迎大家加入，工作地点包括一线城市、重庆和大连。
最近真的忙得不可开交。
前几天和小伙伴聊天时，对他们的迷茫点进行了总结和回顾。虽然这篇文章提到的技术可能有90%在实际项目中不会使用，或者已经通过SAP的升级有了解决方案，但还是做个回顾吧，万一大家遇到这些问题呢。
以下是一些不完全是纯ABAP开发的知识，是从整体到细节的技术总结：
有些技术因为自己也太久没做，所以也当做是对自己的一个技术回顾，快速过一遍：
20年前：
汇编语言：
1.首先是有实验的目的：也就是课程设计和思路。
2.然后是进行设计落地：
3.最后是汇编语言对设计进行机器指令识别验证：
20年前-15年前：
XML/XSLT/JS/JQuery/J2EE等：
因为当时是做产品研发，公司是通过物理手段解决资料COPY（研发电脑直接用胶水堵住USB口），所以完全无法学习公司内部使用的类似Xpage（非XPath）的专利架构。
可以看到这些技术已经完全过时，源代码也失效了。
回顾了之前的例程，现在总结一下，从之前的学习和研发经验中，拥有了从硬件到软件，从需求到设计到落地的完整工作经验（当时对研发的要求包括机房IDC的布线，硬件防火墙策略，raid方案与磁盘带库，以及铜芯心跳都在设计范围内）。
下面给大家简单补充一下，当时的职业规划计算，可以做参考：
硬件方向：要成为能参与硬件设计、硬件谈判的专家，当时预计至少需要7年以上，需要设计、编程、上流水线、流水线旁边的故障台，还有针对不同要求的极限测试房等；软件方向：以当时最熟悉的J2EE举例，至少需要5年时间成为架构师，这个可以通过百度了解；ABAP开发：接下来要给大家讲的ABAP相关需要了解的硬件与组网架构（basis知识，非必须）：就SAP传统的大家最熟悉的方式：传统的SAP开发环境只需要ABAP代码就可以了：DEV（开发环境）-QAS（测试环境）-PRD/TST（生产环境）版本管理通过请求号（也有通过Solution Manager进行请求号管理，不允许直接手工创建）而还有一些特殊的需要用到NWDS开发环境版本管理通过SAP的DTR工具。
2.ABAP相关的应用层技术知识：
下图只有很少一部分，还有很多很多没写的，比如和微软合作的persos已经到3.0版本了，BPC用的也不全是ABAP，还有hybris需要用JAVA等等；
接下来主要想讲讲用得很少的技术，或者说不好百度的技术：
GuiXT（可以被ABAP自开发/Fiori等前端技术取代）：SAP的屏幕脚本技术：可以通过脚本方式修改界面展示。
基于VB的SAP录屏技术（可以被BDC，RPA等取代）最常见应用是主数据顾问应用在excel中，可以实现固定的收集模版收集好数据后，一键进系统。
多说一点，如果是SAP GUI Script的话，结合如下图的录制工具，就可以支持录制脚本，且支持vb、python、java、powerShell等多种脚本语言的导出。
一些基于Microsoft的技术：语音输入技术最早是Voice97，而输出技术早就很成熟了如下代码：
然后是对中文的判断：判断是否包含汉字。
找出字符串中的中文。
同样的原因，可以用OLEDB实现数据库的链接，而不是只有Native SQL与Open SQL这两个选择；应用场景如：2015年左右，SAP的ODBC只支持MSSQL的32位版本，无法支持X64，可以用这套OLEDB方案解决。
多说一点，加上其他的类似ocx调用等，这些可以极大的扩展本身SAP限制不能实现，但是对Windows操作系统又是很好支持的技术。
Freestyle BASIC Script Language这是一个可以用ABAP直接执行API/DLL的技术，但是需要FBSL支持，不像之前的ocx，ole是属于Windows系统本身自带的之前SAP不支持Stock的时候可能用得上，现在的话应该是完全用不上了 主要本身这个技术太老了，Win95时代的技术。
最终总结，其他的前端呢，其实在Fiori啊，SAPUI5啊，没有出来之前还有很多架构可以进行第三方支持（现在也可以，不过现在不再建议了），大家就跟着学习SAP升级后的新技术应该用Fiori就Fiori挺好的。
因为三个点：
- 特殊方案对个人能力要求太高，而且不通用不好运维。
- SAP的新技术发布多是应用层技术，会极大的降低大家的学习成本。
- 如果用的是SAP的升级技术，其实大家之前的代码也不会弃用，可以同步支持。
