Traditionally, JDE core logic executes on the Enterprise Server(s), as C functions, compiled into executable libraries. Next, there are also NER functions, which would be transparently translated into C and compiled into the same kind of executable libraries, with similar lightning fast performance. On top of this layer, there are APPL's, UBE's and TER's, written in interpreted, slower, ER code.

Unfortunately, C language has limitations, exarcerbated by JDE constraints, and at some point JDE started introducing new technologies to free future development from these limitations. Of course, these new technologies depended on new servers, added complexity and risks and were unfamiliar to most of the existing JDE developers, while at the same time were naturally slower than the compiled C code. After a few iterations, JDE current platform for the future development is AIS, but we do not believe that this is a single solution that fits all cases, hence this extensions project.

At the same time, all systems were moving away from client/server paradigm and towards different WEB-centric middleware layers, so the most prevalent form of remote services are now webservices, mostly based on REST/JSON, but occasionally still using XML, or some other protocols. Webservices are now ubiquitous and are no longer avoidable. As a result of these changes vs. the abovementioned BSFN/JDE constraints and the current default AIS solution, a company looking to implement any kind or outboud interface to any external systems would now be required to build and maintain new servers, sacrifice some performance and very probably hire new developers with new skillsets, then it would also require bigger effort and extra time and cost to achieve the desired results.

These new BSFN extensions we are offering here, on the other hand, would take advantage of the well established over many decades, stable and proven core technologies that JDE is built on, which can immediately be used by existing JDE developers, without a need to either re-train them or to hire more developers with different skillsets. These functions are built into executable libraries and therefore would always outperform any external bolt-ons, especially if they are also written in an interpreted language, like Java. Placed at the core of JDE, these functions are directly usable from anywhere in JDE, no interfacing is needed. The development effort, time and cost therefore would be noticeably reduced, delivering instant savings.

The first family of these functions completely resolves all the complexities of working with JSON encapsulation in JDE C or ER code. It offers a comprehensive set of functions to deal with building new and/or parsing return JSON packets in a pleasingly easy fashion. This functionality makes the first family of functions to call external webservices dramatically more powerful and accessible, when the JSON packets in question are beyond a few kilobytes and can no longer be practically constructed by simply concatenating strings.

The second family of extensions are functions to call external webservices. It's flexible enough to perform any WEB operation, like GET or POST, use any encoding, including UTF16 (which AIS does not support), can handle practically unlimited size of data by working around JDE limitations, can process additional headers, authentication, supports TLS channel encryption, and all the other features you would expect, plus works directly with the networking layer on the JDE servers, without any middlemen to slow it down.

And the third family of functions adds Unicode capabilities to pre-Unicode releases of JDE. It does not matter what your default codepage is, because you can tell these functions which codepage you wish to use for every string you process. And in fact you may not need to, because these functions implement heuristics sufficient to automatically select the right codepage for strings with a high degree of accuracy. The resulting strings in UTF8 can be stored in the DB, or files, or passed on to other functions, provided that those functions know how to handle UTF8, like the JSON functions above can.

A set of native JDE BSFN's to easily manipulate JSON structures, load/save from/to strings or files (with support for multiple encodings), with a lot of built-in flexibility.

As JSON typically requires Unicode support, please also see the "Unicode support for XE/ERP8" tab, if you are still on a pre-Unicode release of JDE.

Some screenshots:

Because these functions support saving JSON objects to files and loading them back from files, there are no hard limitations on the JSON length, provided there is enough memory and disk space.

There's another example on the "Unicode support for XE/ERP8" tab as well.

Because JSON is constructed in memory and there is built-in file support, firstly, it allows for storing most common JSON templates on the server for reuse by these functions. Even though any JSON can be built from scratch with this set of functions, for larger structures, using such templates would save time and effort. And secondly, it breaks free from any JDE DD string size limitations: an arbitrary size JSON can be constructed from arbitrary length C strings and saved to a file.

Please, also look at the next extension under the "Webservices" tab: with these JSON functions, it's now functionally on par with AIS, except without any new servers or developers, all built directly into JDE core.

All JDE releases from XE and up to the latest E920 are supported.

Windows x32 bit, x64 bit and Linux x64 bit are supported.

Nothing can be easier!

A single native JDE BSFN to call external webservices, with a lot of built-in flexibility. Here's a screenshot, showing a function call through our BSFN testing tool, with both input and output parameters:

Some more apparent uses of this function can include instantly looking up any exchange rates, or merely invoking some external service by placing a call, possibly passing in some additional data and potentially receiving some data back in real time.

In some cases an external caching server may prove to be desirable to add offloading some or all of these tasks off JDE, serialising the calls, implementing automatic retries to make it more resilient and logging all actions and results for future audits. We have one under development and are looking forward to hearing your exact requirements, so we can incorporate direct solutions for your exact cases into this server. It can be installed and run either on premises, in any cloud, or be hosted elsewhere and even shared among multiple tenants, because it's basically just a relay and requires no access to any internal layers, like JDE data.

Nothing can be easier!

A flexible set of encoding and decoding functions to convert doublebyte ANSI encoded strings to Unicode and back, as well as to Write strings to and Read strings from files.

At the time of release, these functions were implemented: StrToUtf8, StrToUtf16, Utf8ToStr, Utf16ToStr, StrToFile and FileToStr

For instance, StrToFile function is defined as:
BOOL StrToFile(char* AStringInCodePage; int ADefaultCodePage; int AAdditionalCodePages[]; char* AFileName; int AFileEncoding; BOOL AWithBOM; char* ErrOut);

So, it can convert the original ANSI string, without placing any size limits on it, in a single or multiple codepages (including multibyte), to Unicode and write it to a flat file with or without BOM in any Unicode encoding specified, returning a TRUE/FALSE on success/failure and potentially also an error/warning/info message. - the ultimate flexibility!

We can and will add more, as needed, if requested.

Here is an example, a B7334 system, with data stored in the DB in ANSI, in multiple different codepages, which can now be extracted into a JSON structure and saved into a Unicode file, in a fully compliant Unicode JSON envelope:

B7334 AB Data in multiple Codepages:

A simple NER function to extract AB data, convert strings to UTF8, build a JSON structure and save it to a file

Resulting Unicode JSON file contents

Nothing can be easier!

OS: MS Windows (x32 or x64) or Linux (x64)
CPU: Intel/AMD
System Type: Physical or Virtual
JDE Releases: all releases from XE to the latest E920
JDE Backend Database Platforms: DB-Server-independent - all platforms supported by JDE are supported

This software is licensed Per Named Server.

The optional Yearly Update/Upgrade Subscription is available at the time of purchase (not available separately) for an additional yearly fee. It is payable in advance per license, per year. It includes premium support and all software updates released during the paid period. Its cost is calculated as 20% of the product's list price at the time of invoicing, as may change from time to time. Unless the software is purchased for a single use application, we generally recommend to opt in for this Subscription: any future JDE Tools Releases and Releases/Updates may require an updated version of this solution and it's generally more cost-efficient compared to one-off Upgrades.