Configuring GO Publisher and GO Loader Projects

Before configuring GO Publisher and GO Loader, perform the following data preparation tasks for each table that will be managed:

Data Preparation

Note: Ensure that you have not version enabled the database before carrying this out, as it changes the schema. For more information, please refer to Version Enabling Database Data (GO Loader and GO Publisher only).

Add an sms_job_id integer column (typically a NUMBER(n) in Oracle).

This is used to store the job ID within which that feature was last edited, to enable job tracking and change-only validation.

This can be called anything, but the recommended default is sms_job_id. It will be incremented for each job created, therefore it needs to be long enough to store the highest number of jobs possible in the future, for example NUMBER(9).

Note: Ensure that this job ID column name is recorded correctly in the 1Workflow admin page, in order to create specific job types in 1Plan and configure these job types to use one of the Exchange policies.
Ensure each table has a string primary key that will hold a GUID value of 38 characters, typically a VARCHAR2 in Oracle. For easier configuration, call this column IDENTIFIER.
Ensure that the table is suitable to be version enabled by Oracle Workspace Manager.

Typically this means ensuring that the table name or the column names are all no more than 25 characters long. For full restrictions, see the Oracle Workspace Manager documentation.

Note:

If using 1Edit, ensure the data in the database tables are rounded to the same grid tolerance that will be used in 1Edit, and if building topology in 1Edit ensure the data has been all topologically structured together at that tolerance.

If the data has different rounding in the database than in the client, when a feature gets edited and submitted back it may fail validation because the rounded co-ordinates no longer match the surrounding data, so tiny gaps and overlaps may be detected.

A recommended way to achieve this is to use 1Integrate to build topology using at least 2x rounding tolerance (or if building topology in 1Edit, use the same tolerance, typically 10x rounding tolerance) then write it back before rounding it in Oracle. The building of topology removes close vertices and ensures that rounding does not introduce errors.

Before configuring GO Publisher and GO Loader, you will need to get the GML XSD for your data:

Generate Feature Data XSD

Generate the feature data XSD to represent the structure of the data to be served as GML.

You can either replicate the structure of the data in the database (the easiest option), or you may want to change the structure in the GML to a form more suitable for editing.

You may already have a GML structure prepared as an XSD or if not, there are two recommended options:
- To create a schema that is a duplicate of the data structure in Oracle you can use Safe Software's FME to read the tables required from the database and write to GML 3.2.1 format (this will only produce a feature class for Oracle tables that contain rows).
- Create any structure of schema using a tool such as Enterprise Architect from Sparx systems to create a UML model, combined with an open source UML to GML XSD converter such a ShapeChange from Interactive Instruments.
For easier configuration, ensure that the element name for each geometry type matches the name of the column in Oracle.

For example if the column name is GEOMETRY, ensure that it is shown as follows:

<element name="GEOMETRY" type="gml:GeometryPropertyType" minOccurs="0"/>

Configuring GO Publisher

GO Publisher Desktop is used to configure how the GML is exported from the database.

Create a new project and make sure you set the schema repository to be the folder containing the feature data XSD.

This ensures that relative paths are used in the project and therefore it can be deployed within 1Exchange as it will not be hardcoding the paths from the machine used for this configuration step.
Select the feature schema in the repository to add it to the project.

Note: Do not browse to the file. If it is not in the repository, change the repository location.
Keep the default XML root element as gml:FeatureCollection
Connect to a copy of the database feature schema.

This does not need to be in the same database instance or schema name as will be used in production; it must be the same table structure so that the desktop tool can do the correct mapping of the required table names. At runtime, the JNDI connection is used to read from the required database and schema.
In the Project tab, ensure that each table and column to be exported is ticked and mapped to the correct XML path.

When the XSD and the table structure match, the Automatic generation of XML button should match almost everything automatically.
In order for a conflict job to successfully go to a prepared state each table name in the GO Publisher project requires a unique key.

In the SQL Filters tab, for each table select Edit on the right-hand side.

Populate the Unique Key column, click OK and then click Save.

Note: If you open the GO Publisher project in a text editor, you should see the unique key is now declared (e.g. uniqueKey="IDENTIFIER").

Note:
If the unique key is not set, you might see the following error in the 1Exchange logs:

Could not obtain results from _CONF table: ORA-00904: "null": invalid identifier

Configuring GO Loader

GO Loader Desktop is used to configure how the GML is loaded into the database:

Ask 1Spatial Support for the GO Loader plug-in used to set the job ID on data load.

This file is called go-loader-workflow-plugins[version].jar and should be copied into the GO Loader plug-ins folder at: \Program Files\Go Loader [version]\plugins.
Get the GML XSD for your data and also extract the cou-gml-update.xsd XSD from your installation zip file (located in: ms-exchange-release-[version]-release.zip\ms-exchange-release-[version]\install\dependencies\goloader\gl_product_template\schemas).
Create a new GO Loader project, and using the GML Schema tab, add the two XSDs mentioned above and then parse the schema.

Note: Ensure you have both of the correct XSDs. Any modifications to these XSDs will require the next steps to be repeated. If you omit the cou-gml-update XSD, no features will be written to the database.
Ensure that the filter in the GML filter tab includes the featuretypes and columns that need to be extracted and do not include any properties that start gml: with the exception of gml:identifier which must always be included.

If the XSD does not use named geometry properties and includes gml types such as gml:GeometryPropertyType instead, include these types as well.
Within the Translations tab, visit each featuretype and property and check that the table name and column name is correct.

Having a GML structure that matches the Oracle structure makes configuration easier because they will already be matched.

Ensure that you make the following changes:
- The only GML property that has to be set to Insert should be the top level gml:identifier which should have the column value set to the value of the primary key column in the database (this is why it helps to call that column IDENTIFIER). Discard the gml:identifier codespace sub property.
- Right-click on the table name and select the jobname must be Integer plug-in.
  
  Insert the plugin:AsInt value and ensure it maps to the correct job ID column in the database (for example, sms_job_id).
  
  Discard the plugin:AsString value.
  
  If sms_job_id is in the list of GML Elements for this table, the translation method needs to be set to Discard so that the user can map the ASInt to sms_job_id.
- Ensure each required geometry property is set to Insert and maps to the correct geometry column in the database.
- Ensure that all geometry sub properties such as srsDimension or gml:identifier are set to Discard.
In the Tables tab for each table, right-click on the primary key column (typically IDENTIFIER) and select Set the column as the table's Feature ID column.