JD Edwards E1 Business Services Server BSSV alternate ending
JD Edwards has come a long way and so has Inter-operating with it. Interoperability with Xe started with GenJava, GenCOM , matured with XPI, WSG (webMethods). Oracle has come up with BSSV as their future of Interoperability with JD Edwards which Oracle calls native to E1 Toolset.
While its true that you can develop, and deploy Business Services using standard JDE package management and migration tools. Its still not native because BSSV’s are written in Java using JDeveloper. For me native would mean some solution written in C which is what Business Functions and NER’s are written in.
With BSSV you can expose EnterpriseOne business functionality as webservices and also consume external webservices. In short BSSV is a webservices wrapper to E1 Business processes. If you are wondering if webservices can be implemented using ‘C’ , yes it can be , Apache Axis2/C is an excellent web services engine, it supports SOAP1.1 and SOAP1.2 as well as REST style of webservice programming
Not to confuse with Oracle’s SOA and fusion architecture and strategy. You can architect your system using SOA Design principles even in C. Either way Oracle Fusion is the right way forward for JD Edwards customers
Coming back to my point, BSSV is a java application-framework which runs on a application server like ‘Oracle Application Server’ or WebSphere (only 2 servers certified for BSSV). BSSV connects to E1 Enterprise Server through a java connector under the hoods.
Lets ‘C’ how it would have panned out if BSSV was implemented in C programming language. For clarity I am going to call BSSV as Java-BSSV and the alternate ending as C-BSSV
C with this approach you would write a C Business Function in OMW and the system will create the webservices Handling partfor you when you deploy it to server. All the classes you have to write in Java-BSSV will be eliminated I am talking about Value Classes, Config Classes etc etc. The C-BSSV can call Business Functions, Table I/O, UDC, Processing Options, Soft Coding etc natively. This approach will work on all platforms windows and unix based. A C-Business Function programmer can verify this for you.
Why I wanted the alternate ending
The bulk of JD Edwards is written in C programming language, millions and millions of lines of code. There is no way you are able to transition away from ‘C’. As far as JDE is concerned Oracle will have to do develop and enhance these C codes, so why introduce a new language in the mix and in doing so another transition point and potential point for failure.
Lets see how past E1 integration frameworks worked, and we will contrast it with BSSV. Brace yourself its going to get real technical. To list a few are GenJava, GenCOM, and XPI
First we had GenJava, in which you ran an exe process which generated Java-Stubs or classes. You would then import these stub-classes in your Java Applications for calling C-Business functions within JD Edwards. This approach was the only realtime option available and it worked well for the most part. At the heart of this framework was the connector.jar which provided connectivity with JDE Xe. The weakest link in this approach is the connection between java class and E1 server
Along came XPI which is rebranded webMethods. XPI had the concept of Adapter which is a java connector, which was configured through AdapterManager a java based program and later a web based console. You would provide it with username, password, servername port etc. you would create AdapterServices to call the business functions. The weakest link in this approach is the connector between 3rd party(XPI) and E1 server
WSG which ia again WebMethods added a webservice layer to E1 , WSG also had the connector architecture, so Does Java-BSSV



