Known issues in OpenEdge 12.5

Two new methods have been added to the IWebRequest interface: GetRawEntity() and GetTypedEntity(). Any classes that implement this interface must implement these methods.

GetRawEntity() is intended to return an object containing the bytes of a request's message body, or an empty object if none is sent.

GetTypedEntity() is intended to return a "strongly typed" object that matches the request's ContentType, or an empty Memptr instance if none is found. This differs from the Entity property in that the Entity property converts only specific content-types (certain JSON and XML content-types); this method converts all that it can.

If a test method expects a Progress.Lang.AppError to be returned, then in cases where the code being tested did not return such an error, the test (incorrectly) passed prior to this fix.

For example, a test like the below expects an AppError to be the result of the Parse method.
class TestError:
    @Test(expected="Progress.Lang.AppError").
    method public void Parse_HasPercent_Err():
        URI:Parse('http://localhost?filter=WHERE').
    end method.
end class.

The Parse() method does not thrown an exception but the test passes anyway, because ABLUnit threw an Progress.Lang.AppError to indicate that the error that was supposed to be thrown, was not thrown. This thrown-by-ABLUnit AppError was interpreted as being the expected error and so the test method was marked as "passed". This is a false positive - the test method should have failed with the "No exception is raised but expecting ..." message.

ABLUnit has been fixed so that a different error is thrown and processed to indicate that the expected error was not raised. ABLUnit now throws an OpenEdge.ABLUnit.Runner.ExpectedExceptionError error when it detects that the test method did not throw an error and should have.

A consequence of this is that tests that were previously passing will now fail. These tests should be examined and the test or code being tested fixed, where applicable.

These tests will all have the following annotation
    @Test(expected="Progress.Lang.AppError").
or
    @Test(expected="AppError").

If a test procedure (test case) is somehow deleted while it is running individual Test-annotated internal procedures, then the test case and its Before-annotated lifecycle procedures are re-run before running the next test procedure.

This reverts behaviour from 11.7.3 , which was removed in 11.7.6, and adds the running of the Before-annotated lifecycle procedures.

Deployment of the OpenEdge 12.5 java open client requires an additional .jar file. Ensure that <OpenEdge Installation>/java/ehnlog.jar is included in build, test, and deployment environments for java open client. This is a new jar file previously not required. You can find the full list of required .jar files in the documentation at: https://docs.progress.com/bundle/openedge-java-open-clients/page/Java-Open-Client-Runtime-package.html.

An ABL Application might terminate, when user defined function is used along with Single Table Server-Side Aggregate Function (SSA). Single Table Server-Side Aggregate functions are COUNT, AVERAGE and TOTAL.

For an example, below ABL statement might result in termination of ABL client, where “tfun” is a user defined function.

AGGREGATE totalBalance = TOTAL(Balance) FOR Customer WHERE tfun(NAME) = "abc".

Please follow the recommendation provided at https://docs.progress.com/bundle/openedge-startup-and-parameter-reference-122/page/No-UDF-in-WHERE-Clause-noudfinwhere.html?labelkey=product_openedge_122  to avoid any issues at runtime and catch these during compile time itself.

Starting with OpenEdge 12.5, the Progress Developer Studio for OpenEdge (PDSOE) has been enhanced with a model to provide a better developer user experience for tools like find references, content assists, and intelligent compilation. This new model performs an initialization process when a project gets created. For an existing project, a one-time initialization happens automatically. Afterward, PDSOE keeps the project up to date incrementally as your code changes. 

Note, Updating an include file used in many other source files results in reconstructing the model for all the files where the include file was referred. Additionally, modifying an include file referred in other include files reconstructs the model for all files referring all include files.


For large, complex projects, the initialization for large, complex existing projects can be lengthy, and so a tool is provided to proactively perform the initialization. The initialization stores the source code information in logical structures to improve the performance of the tools, however, it can take significant time and system resources compared to PDSOE available with previous OpenEdge releases. You can find details on the “Initialize OpenEdge Tooling” process at https://docs.progress.com/category/openedge.


Additionally, in some conditions, the new model is not getting updated incrementally. You can always rerun the Initialize OpenEdge Tooling to get the model updated as necessary. Known issues are,

* Icons in the find reference search results in the search results view are only present for the files open in the editor
* Information is not properly updated when an include or class file is referenced by another file in the project before the file is added in the project
* Find references across the workspace doesn’t work for variables of type Query and Data-Source
* The model does not work for linked files and folders


Note, any file modified outside of PDSOE will be processed after refreshing the project to detect the changes in the file or when the PDSOE is restarted.

The profiler statistics are disabled in Progress Developer Studio for OpenEdge(PDSOE) by default to reduce the profiling overhead. Due to this change, the following information will not be visible in the profiler view for a profiling session,

* Database information in the AVM information tab
* Information like startup file, character set, etc. in the parameters filed in the AVM information tab

To enable statistics in the profiler add the variable *PROFILER_STATISTICS=TRUE* by navigating to the Environment tab in the profiler’s Run Configurations.

When there are multiple OpenEdge 12.5 installations on a single Linux 64 machine with at least one installation being registered with External Security Administration Manager (ESAM) by executing initdlc script but not all installations registered because some installations have not run the initdlc script.  If after the ESAM is installed, the default policy is changed to “OESEC_POL_QUALIFIED_BLOCK_ACCESS, then applications from other installations where initdlc was not run and are not registered with ESAM might terminate if they attempt to use an invalid DLC path.  This can disrupt operations in installations that have not been registered to the ESAM.

Workaround: Change the policy back to “OESEC_POL_NO_ACTION” in policy file /etc/openedge.d/conf/oesec.pol or run initdlc in the installations that have not yet been registered.