Skip to main content

OpenEdge Datatypes for Enterprise Architect

  • warning: Illegal string offset 'files' in /home/cintegri/public_html/modules/upload/upload.module on line 281.
  • warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/cintegri/public_html/includes/ on line 349.
  • warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /home/cintegri/public_html/includes/ on line 349.
  • warning: Illegal string offset 'files' in /home/cintegri/public_html/modules/upload/upload.module on line 281.
Printer-friendly version

As of version 7.1, Enterprise Architect does not come supplied with datatype definitions for OpenEdge. There is a Utility provided by PSC under PSDN Code Share which includes these datatypes along with other functionality, but there are some issues with that implementation. Also, that Utility does not currently provide the option for loading the datatypes separately from the stereotypes that are also in that Utility and these stereotypes are at variance with the proposed UML Profile for ABL.

Therefore, an XML file is provided here for independently loading datatypes appropriate for use with the proposed Profile. These datatypes should be suitable for any use of EA with OpenEdge. They are provided as open source and so may be customized to taste by any user. We will note differences between the implementation in the Utility and the present implementation as appropriate. All reference to "Utility" refers to the one provided at the links on PSDN Code Share above.

Differences from the Utility implementation
There are a number of differences between the implementation provided by the Utility and the implementation here. These include:

  1. EA's datatypes come in two types, Code and DDL. DDL applies to database tables and Code applies to programming languages, which in most cases are independent from the database. For OpenEdge, there is a single coherent product, but still there are differences between the two since some ABL datatypes, e.g., COM-HANDLE, are not datatypes usable in the database schema. The Utility includes only Code datatypes, but this implementation includes both. (We have been told this is a limitation of the technology used in the Utility).
  2. The implementation in the Utility includes no mapping to generic datatypes (see below). This implementation includes such mappings.
  3. The technology used in the Utility to add the datatypes is such that the DatatypeIDs are assigned to consecutively follow the pre-existing datatypes. This XML file was designed to be loaded with Resource Import (see below), so DatatypeIDs starting at 1001 for Code and 2001 for DDL have been assigned to keep them safely above the standard datatypes which go up to 375 as of EA 7.1.817.
  4. The implementation in the Utility includes two product names - "OpenEdge ABL" and "OpenEdge OO". These seem to be identical except that the "OpenEdge ABL" set includes int64 and the other does not. We have been told that the intent in having two product names was to preserve the code generation facilities which existed prior to the addition of OO extensions to ABL under its own product name. Here, we have used "OpenEdge ABL" for all Code datatypes and just "OpenEdge" for all DDL datatypes. Code and DDL product names need to be different to avoid undesirable side-effects in EA. Our expectation is that one product name for all Code datatypes is sufficient since the selection and implementation of any code generation templates will be determined independently and thus one can provide for OO and non-OO generation without making a duplication of the datatypes.

Discussion of columns used
In the EA schema, which is not yet documented, there are 18 columns in the t_datatype table which is used to store the datatypes. My assumptions about the meaning of these columns in building this dataset are as follows:

Type Code or DDL to indicate usage domain.
ProductName Indicates a set, "OpenEdge" is used here for DDL datatypes and "OpenEdge ABL" for Code datatypes.
Datatype The name of the datatype.
Size Purpose unclear. Left as 0.
MaxLen Maximum length. Only defined for character, CLOB, and decimal.
MaxPrec Maximum precision? Only defined for decimal.
MaxScale Maximum scale? Does not apply to OpenEdge. See note below.
DefaultLen Default length. Only defined when MaxLen is defined.
DefaultPrec Default precision. Only defined for decimal.
DefaultScale Default scale. Does not apply to OpenEdge. See note below.
User 0 for defined by Sparx. 1 for defined by other.
Pdata1 Not used.
Pdata2 Not used.
Pdata3 Not used.
Pdata4 Not used. See note below.
HasLength Has length characteristics. Not used in Sparx samples, so not used here.
Generictype See note below.
DatatypeID A number used to reference this datatype.

In the Utility implementation, Pdata4 is given the value "TechID=OpenEdge;". This assignment is apparently an artifact of the technology used in the Utility. No Sparx standard datatypes have any value in this column. This assignment has been dropped in the implementation here.

GenericType suggests a mapping onto a standardized, generic domain such as might be used in a Computationally Independent Model or Platform Independent Model prior to determining a target technology. However, its use in the Sparx samples is more often to duplicate the Datatype name. In the current work, we have taken the route of using the SQL equivalent for the datatype when possible and of using generic forms such as "handle" for those that have no SQL equivalent. See Table 2-10 of the Database Administration manual for mappings.

MaxScale is defined for all datatypes with a value of zero in the implementation in the Utility, although this also seems to be an artifact of the methods used, not something done intentionally. In the datatypes supplied by Sparx, no MaxScale is provided for the Code datatypes for VisualBasic, C++, Java, or C#, so it is provisionally omitted here. DefaultScale does not apply to OpenEdge, although it is defined for most datatypes supplied by Sparx. It is provisionally omitted here until it is clear that it has some impact. With both values omitted, MaxScale has a value of 0 anyway and DefaultScale has no value.

To install, open a project in EA, select Tools from the menu, select Import Reference Data, browse for the downloaded file, select, highlight the dataset for "Model Data Types for OpenEdge - Code and DDL" and press button to complete. To avoid having to do this for every project, do the addition in EABase or other suitable base project from which new projects will be derived.

Version History
13 December 2007 - Original - untested
14 December 2007 - Revised, change Code to OpenEdge ABL - limited testing
15 December 2007 - Revised, drop MaxScale, DefaultScale, and PData4 - no new testing.