Mapping File Syntax

This statement (or the schema statement) must be the first line in the mapping file.

If you use the server statement, do not use the schema or directconnect statements.

Use schema instead of server if you use schema names instead of database links (by setting MX_USE_SCHEMA_NAMES to true in the .ini file(s).

This statement (or the server statement) must be the first line in the mapping file.

item Username USER;
item Password PASS;
item ConnectString CS;
item Driver DRIVER_TYPE;

These transactions are not XA transactions. Commits to 3DSpace and the adaplet database are done separately.

For more information, see Direct Connection to the Database.

#mode readonly;
#mode readwrite;
mode extend;
#mode migrate;

The operating mode set for an adaplet can change over time. For example, you can change a readwrite adaplet to extend to adjust for changes to the business model. Not all adaplets will support all operating modes. You can change the mode from readonly or readwrite to migrate or extend.

Changing the mode from migrate or extend to readonly or readwrite is more difficult and can result in loss of data. Before making this change, you must clear the adaplet vault. This will not affect data in the foreign database, but it removes any extended data that 3DSpace might have added.

For more information, see Operating Modes.

#### physical tables
table NAME {
COLUMN_NAME DATATYPE [primary];
...
vault STRING;
}

For more information, see Physical Table Descriptions.

table VIRTUALTABLENAME {
join TABLE,TABLE,TABLE...
where EXPRESSION
}

The join statement lists the tables to be joined. The where EXPRESSION keyword uses Oracle or SQL expressions to describe the association between tables.

For more information, see Joined Tables.

#### ENOVIA types

type TABLE(COLUMN) [using TABLE(COLUMN)] [alias name] {
id TABLE(COLUMN);
name TABLE(COLUMN) [using TABLE(COLUMN)];
lockbus TRUE|FALSE;
policy TABLE(COLUMN) [using TABLE(COLUMN)];
owner TABLE(COLUMN) [using TABLE(COLUMN)];
default policy POLICY_NAME;
default owner USERNAME;
next EXPRESSION;
revision TABLE(COLUMN) [using TABLE(COLUMN)];
nextrev TABLE(COLUMN) [using TABLE(COLUMN)];
prevrev TABLE(COLUMN) [using TABLE(COLUMN)];
description TABLE(COLUMN) [using TABLE(COLUMN)];
icon TABLE(COLUMN) [using TABLE(COLUMN)];
locker TABLE(COLUMN) [using TABLE(COLUMN)];
created TABLE(COLUMN) [using TABLE(COLUMN)];
modified TABLE(COLUMN) [using TABLE(COLUMN)];
state TABLE(COLUMN) [using TABLE(COLUMN)];
attribute ATT_NAME TABLE(COLUMN) [using TABLE(COLUMN)];
}

When only a COLUMN is specified, the previously stated TABLE is assumed. The using clause syntax is not allowed when running the SQL Loader (for more information, see Specifying Data from Multiple Tables. As a workaround, see Joined Tables.

Object uniqueness (type/name/rev) is enforced at the schema level. Depending on the legacy system implementation and this definition, it could be possible to create objects with duplicate type/name/revisions. You must either eliminate this possibility (by ensuring the foreign schema enforces unique type/name/rev), or accommodate duplicate type/name/rev in any application code that accesses the adaplet vault.

Columns in a foreign table that correspond to Type, Name, and Revision must be managed to support the 3DSpace assumption of Type/Name/Revision uniqueness within a vault. Failing to do so can result in inconsistent behavior because it is indeterminate which of the multiple objects will be returned for a given Type/Name/Revision.

For example:

type Department {
  id DEPT(DEPTNO);
  next "max(DEPTNO)+10";
  name DNAME;
  attribute "Department Number" DEPTNO;
  attribute Location LOC;
  default policy Departments;
  default owner scott;
}

derive TYPENAME;
type TABLE(COLUMN) alias NAME;

The type hierarchy in the adaplet is independent of the type hierarchy in 3DSpace. The leaf types in the adaplet must match the leaf types in 3DSpace, but the parent types are independent. The adaplet type hierarchy should reflect the data structure in the foreign database and should be no more than two levels deep. In general, you will have one parent type per table. Each parent type will have no more than one level of child types.

The type TABLE(COLUMN) alias NAME statement indicates how the type is specified in the column, and how it should be used in 3DSpace. For example:

type Clerk {
  derive Employee;
  type JOB alias "CLERK";
}

For more information, see Oracle Sample Table Structures. The EMP table uses the JOB column to define the subtype for that row. Specify each different entry in this column as a type in the mapping file, and create the Types in 3DSpace.

name ENAME;

The Employee type objects get their names from the ENAME column. When the table containing the ID is provided, TABLE defaults to that table. As a result, ENAME is a column in the table named above in the ID statement, EMP.

Once the table containing the ID is provided, this TABLE can be defaulted.

If data exists that can be used for policy names, it can be mapped with the policy TABLE (COLUMN) statement. If policies are defined in this manner, all of the policies in the table must be created using MQL.

If data exists that can be used for owner names, it can be mapped with the owner TABLE (COLUMN) statement. If owners are defined in this manner, all of the persons in the table must be created using MQL.

The default is false. If set to true, the SQL for the initial lookup when modifying a foreign business object selects the row with the additional specification “for update.” When set to false, the data could be updated by a concurrent session at the same time.

Do not use true if the connection to your adaplet vault is readonly, even if the mode of the adaplet is extend or readwrite.

next "max(EMPNO)+1";

When used with an Oracle sequence, the adaplet sometimes appends the types table name to whatever is specified by the next statement. To avoid this, use the keyword from in the next value. For example:

next "SEQUENCE_NAME.nextval from DUAL";

The sequence must be enclosed in quotes. DUAL is a built-in table in Oracle that is commonly used for this purpose.

To set the next object ID to a unique object ID for an integer column (number(10) will suffice), use hashed as the value. The column must have a unique constraint. For example, this code enables hashed id generation for the ID column of the PART table that maps to the 3DSpace type “Part:

type Part {
id PART(ID) mapped;
next hashed;
type PART(TYPE) alias "Part"; 

prevrev TABLE (COLUMN) [using TABLE (COLUMN)]

prevrev "Revisions" PREVIOUS;

relationship RELATIONSHIPNAME {
  id  TABLE (COLUMN);
  next EXPRESSION;
  delete OPTION;
  from TYPENAME in TABLE(COLUMN);
  to TYPENAME in TABLE(COLUMN);
  attribute ATTRIBUTE_NAME TABLE(COLUMN);
}

If a relationship has attributes, a relationship ID is required. The syntax for relationship IDs and attributes is identical to IDs and attributes on business types.

Using OIDs provides better performance than using Type/Name/Revision. Cardinality, allowed types, and other rules of relationships are enforced by 3DSpace and not the adaplet.

• nullfrom to null out the from column
• nullto to null out the to column
• remove to remove the row

For example:

relationship "DeptGrade" {
  id DEPTGRADE(DEPTNO,GRADE) mapped;
  delete remove;
  from Department in DEPTGRADE(DEPTNO);
  to "Salary Grade" in DEPTGRADE(GRADE);
}

The row that contains the relationship DEPTGRADE will be removed.

item ExportFieldDelimiter 1C;

Item ExportRecordDelimiter 1E;