The G/Technology runtime environment is great and I haven’t seen much issues with it working at KPN Netherlands from 2009 until recently. A whole different story is the G/Technology developer experience and I’m very frustrated about it :
There’s no clean distinction between development and runtime environment
In G/Technology your feature definitions are stored in the database and made available for clients through a process called ‘metadata publishing’. This process calls some procedures and packages in the database to gather all the information needed, store it in temporary tables called ‘optimized tables’and then writes the content of these tables to a folder as .raw files:
G/Technology metadata folder
This folder then is read runtime and much of the information in the database is not needed anymore. All the tables starting with G3E.., much of the Oracle packages and procedures are only needed at development time, not runtime. In my view this is a clear polution of the database and mixing of concerns. A better way would be to make a clear distinction between a development-scheme and production-scheme and maybe take of all the generating-procedures from the database and store them somewhere else. Visual Studio T4 templates would be an ideal candidate to replace the code generating packages in the database.
It takes to much time to test and debug your features
Back in the days of FRAMME, you had a great tool called ‘Framme Knowledge Based Tools Rulebase Builder’ or FRMKTRB/FRMKTNUC as I recall its product name was, and it essentially was a feature definition generating tool (a rulebase is what you know would call metadata). It would allow you to generate, compile and test your feature definitions fast, easy and in a very user friendly way. The only downside was that it was not multiuser-enabled and it had its own datastore to store definitions. The options you have now for developing your definitions are either one of these :
- The G/Technology project tool
- Metadata explorer from within G/Technology
- Use SQL-scripts
The G/Technology project tool is full of bugs and cannot be used to develop a complete feature. For instance, it lacks generation of placement functions and metadata cannot be published from inside it. I cannot believe Intergraph has ever done a full test on this product for version 10.1.0 regarding the bugs it contains.
G/Technology project tool
You can use Metadata Explorer from within G/Designer to develop a complete feature, but it is very user unfriendly and the descriptions a user sees are not easy to understand. It does have a way of publishing metadata or only publish the changes you made, but this doesn’t work 100%. G/Designer Metadata explorer can be used to review your definitions, but you can also generate new ones so it actually is a development tool. Since G/Designer also is the tool of choice for manipulating facility data, I cannot understand how a development tool like metadata explorer got stuck in G/Designer.
G/Technology metadata explorer
The only bullet proof way of developing your feature definitions are SQL Scripts. You can define your definitions using SQL-scripts, call some generation procedures/packages for generating the necessary packages and triggers, publish metadata and test your definitions. You need to have a very solid knowledge of how the metadata-tables relate to each other and how to use them. This is the only really working method today, but it is very time consuming and requires much knowledge.
Regardless of the tool you will be using and the knowledge you have of G/Technology, developing your definitions can be very hard and will be time consuming and Intergraph needs to improve on that. In my opinion, it would be a good idea to use a tool somewhat like the old FRMKTRB tools, and let it generate directly into your .RAW files for quick testing, but also generate SQL-scripts for adding your definitions to a database where there would be at least 2 schemas for G/Technology, a development- and a production scheme. This way it would be possible to do your quick testing but also enable multiuser development.
GPT is a good starting point for building new features, but the saved sql generated must be edited to provide logical feature numbers and names. Once the sql scripts have been run in your development schema, changes are easy to make through Metadata Explorer. Having a template script to pull the table data from the development schema allows the feature definitions to be migrated to a QA schema and eventually a production schema. For instance, this sql will generate the insert statement for the G3E_FEATURE table:
select ‘INSERT INTO G3E_FEATURE (G3E_FNO, G3E_USERNAME, G3E_TOOLTIP, G3E_PRIMARYGEOGRAPHICCNO, G3E_PRIMARYATTRIBUTECNO, G3E_DCNO, G3E_PRIMARYDETAILCNO, G3E_NUMBEROFNODES, G3E_IMPORTFEATURENAME, G3E_REPLACE, G3E_NAME, G3E_MERGE, G3E_CLASSIFICATIONANO, G3E_IDENTIFIERVIEW, G3E_BULKEDIT , G3E_ICONORDINAL, G3E_EDITROLE, G3E_SELECTROLE, G3E_DELETEROLE, G3E_RINO, G3E_RIARGGROUPNO, G3E_EDITDATE)
‘ || ‘
VALUES(‘ || G3E_FNO || ‘,”’ || G3E_USERNAME || ”’,”’ || G3E_TOOLTIP || ”’,”’ ||
G3E_PRIMARYGEOGRAPHICCNO || ”’,”’ || G3E_PRIMARYATTRIBUTECNO || ”’,”’ || G3E_DCNO || ”’,”’ || G3E_PRIMARYDETAILCNO || ”’,”’ || G3E_NUMBEROFNODES || ”’,”’ || G3E_IMPORTFEATURENAME || ”’,”’ || G3E_REPLACE || ”’,”’ || G3E_NAME || ”’,”’|| G3E_MERGE || ”’,”’ || G3E_CLASSIFICATIONANO || ”’,”’ || G3E_IDENTIFIERVIEW || ”’,”’ || G3E_BULKEDIT || ”’,”’ || G3E_ICONORDINAL || ”’,”’ || G3E_EDITROLE || ”’,”’ || G3E_SELECTROLE || ”’,”’ || G3E_DELETEROLE || ”’,”’ || G3E_RINO || ”’,”’ || G3E_RIARGGROUPNO || ”’,SYSDATE);’
where G3E_FNO in (100, 200, 300)
order by G3E_FNO;