Known issues in OpenEdge 12.7

Behavior Change: Processing of errors in a Business Entity now throws error object with multiple error messages. In previous versions, an object with only the first error message was being thrown.

Use of the OEManager webapp is one of the primary recommendations for managing a PAS instance, though communication with the available RESTful API’s must be created from scratch if intending to use programmatic access. For this purpose the OpenEdge.ApplicationServer.Util.OEManagerConnection class was created to assist OOABL developers. Each instance of the class creates a reusable ABL HttpClient connection definition against the OEManager webapp deployed to a PAS instance. Once a connection is defined the class methods included in the class offer easy access to common actions and queries which may be encountered while managing an instance (all of which utilize substitutions of values for URI’s defined in a new OpenEdge.ApplicationServer.Util.OEManagerEndpoint class).

Prerequisites:

• Installation and securing of the OEManager webapp (oemanager.war) to a running PAS instance
• Inclusion of the ServerAdmin.pl in the PROPATH for any ABL code which intends to utilize this class.

As an example, the following creates a reusable oMgrConn object for a PAS instance at http://localhost:8443 secured by “myuser:mypassword”.

using OpenEdge.ApplicationServer.Util.OEManagerConnection.
using Progress.Json.ObjectModel.JsonObject.
using Progress.Json.ObjectModel.JsonArray.

define variable oMgrConn  as OEManagerConnection no-undo.
assign oMgrConn = OEManagerConnection:Build("https", "localhost", 8443, "myuser", "mypassword").

Once the connection is defined any available method can be accessed which will send a request to the PAS instance to obtain the requested data or to perform a specific action. In the usage below this will return a list of all ABL Applications deployed to an instance by use of the GetApplications() method.

define variable oABLApps as JsonArray no-undo.
assign oABLApps = oMgrConn:GetApplications().

This example shows the use of parameters for the GetAgents() method. In this case, to return all agents an ABL Application name must be provided.

define variable oAgents as JsonArray no-undo.
assign oAgents = oMgrConn:GetAgents("oepas1").

Requests to alter server operation are also supported. The StopAgent() method will stop an agent (identified by an Agent ID) for an ABL Application “oepas1” using values for the “wait to finish” and “wait after” parameters expected for this action.

oMgrConn:StopAgent("oepas1", "<agent_id>", "120000", "60000")

Common actions may also result in common outcomes. In this example the GetOpOutcome() method will look for specific properties in the result of the StopAgent() method and produce a user-friendly string for display.

message oMgrConn:GetOpOutcome(oMgrConn:StopAgent("oepas1", "<agent_id>", "120000", "60000")).

A primary benefit of this new class is that any expected error handling or invalid responses from the server should be gracefully handled by the included code, removing the need to create this logic. The result of any query to the server should be a valid JSON array or object, even in the event of an error (the construct will just be empty). Errors and other messages are automatically sent to a log file which can be adjusted through use of the ABL Logger framework.

When installing OpenEdge 12.7 on a Windows system, you may see a ‘Cannot continue installation’ dialog box, requiring you to abort the installation. This issue occurs if OpenEdge 12.6 is running on the same Windows system. Libraries in use need to be updated during the OpenEdge 12.7 installation process. Please install 12.7 after you can safely shut down the running 12.6 application, and shut down any automatically started Windows services used by OpenEdge. For more information, refer the KB Article 01297178.

Support for the smaller database block sizes, 1024 and 2048 kilobytes, is deprecated in OpenEdge 12.7.  This applies to creating a new database and starting up existing databases. 

 To determine if you are affected by this:

• The larger sizes, 4096 and 8192, were introduced in Progress V8.2.  The defaults were changed early in OpenEdge 10.x to 4096 for Windows and Linux.
• Identify your database block size using PROUTIL DESCRIBE and locate the Block Size in the output.
• To change the database block size you must perform a DUMP of the data and LOAD it into a database with a new structure. This can be done with your current version of OpenEdge. 

When existing databases with the smaller block sizes are recreated with a larger block size they experience less system paging.  They also can take advantage of features only available with the larger block sizes, for example large index key entries.

Use the new parameter Host Name Aliasing (-hostnameAliasing) to allow a hostname alias or specific IP address for the Host Name (-H) instead of specifying the actual server hostname.

Without -hostnameAliasing the -H value must match the server machine name. If more than one IP address is configured associated with that hostname, then all IP addresses are listened upon allowing remote clients to communicate using any of the configured IP addresses.

-hostnameAliasing takes no parameters. This startup parameter allows the DBA to control which Network Interface Card (NIC) is used for OpenEdge database network communication through host name alias configuration or specific IP address.

A host name alias can be configured and associated with only one of the NICs. Specifying this hostname alias for the -H parameter will restrict access from remote clients to only use the one configured IP address for this host name alias. If more than one IP address is configured for the server hostname or hostname alias, database startup with -hostnameAliasing uses only the first IP address configured.

By default, Host Name Aliasing is disabled, and you must specify the server hostname with -H

Note: The above description only applies to IPv4 host names. IPv6 already allows similar behavior.

If the database-request statement cache information for a client exceeds 256 bytes of shared memory, it is stored in a temporary file. You must specify a directory for these temporary files, and you may do so using PROMON, VST, or a startup parameter. Previously it was only allowed via PROMON.

PROMON:
To specify a directory using PROMON,

• Choose option 8 in the Client Database-Request Statement Caching menu.
• Enter the name of the directory. The directory name cannot exceed 255 bytes in length and must be created prior to accessing this option.

VST:
You can also specify the directory using the _DbParams VST.
Startup parameter:
Use the Client Database-Request Statement Caching directory (-clstmtcachedir) to specify the location for storing temporary files of cache information that exceeds 256 bytes of shared memory.

When the parameter (-clstmtcachedir)  is specified, it must be followed by an existing directory name. If the directory does not already exist an error will be reported and the database will not be started.

The parameters configured in the Java Open Client ParamArray class would not always be reset in a consistent manner. In some scenarios the configured parameters would be set to null, and in other cases, the parameters would be left alone, even if there were changes some of the OUTPUT or INPUT-OUTPUT parameter values.  

The reset behavior is now consistent with the .NET Open Client for OpenEdge 12.7.  The current behavior will reset the configured parameters to null if an error occurs while processing the AppServer request if any of the OUTPUT or INPUT-OUTPUT parameter values have changed. If no changes have been made to any of the parameters while processing the request, the reset is not performed.

The reset behavior can be controlled using the setInputErrorResetPolicy() or the setOutputErrorResetPolicy() functions on the ParamArray class.  See the Java Open Client documentation for additional details.

Starting with OpenEdge 12.7, when an exception is thrown in .NET Open Client performing a request against the application server, the parameter configuration stored in the ParamArray object are no longer reset if the values remain unmodified from their original assignment prior to executing the application server request.

You can return the old behavior by assigning the InputErrorResetPolicy and/or OutputErrorResetPolicy properties of the ParamArray to RESET_ALWAYS. For more details see the documentation regarding error handling with .NET Open Client.

In a scenario where HTTPS server configured with Client Authentication and the ABL Client (or) ABL Http Client is not sending the required client certificate then the expected error is “Connection failure for host <host> port <port> transport TCP. (9407)”.

In OpenEdge 12.7 release, when an ABL Client (or) ABL Http Client is using TLS 1.3 for TLS handshake the default error pop-up message is now changed to “Socket connected is not true”. To confirm whether you are encountering this problem or not, you could enable Client logging and search for the message “read:fatal:bad certificate”.

Here is the article on how to enable client logging https://community.progress.com/s/article/P121819#:~:text=To%20turn%20on%20SSL%20debug,them%20to%20pick%20this%20up