Show the user the ENS-generated name before creating the object - SmartPlant Foundation - IM Update 44 - Customization & Programming - Hexagon

SmartPlant Foundation Customization

Language
English
Product
SmartPlant Foundation
Search by Category
Customization & Programming
SmartPlant Foundation / SDx Version
10

This was put together as part of the first beta training session. It emulates a specific 3.x customization. The requirement is that the user wants to know what the name being generated by ENS is before they commit to creating the object.

To perform this customization the DEVENSClass1 ClassDef was used because it had already been configured for ENS. It would be very straightforward to change the code for another object.

Both client and server code had to be written to enable us to do this. On the client side we had to override the Create wizard. This allowed us to trap the Finish and Apply button click. This is performed by the OnFinish method, and that's the only client side change we made. The logic is as follows:

  • Extract the item to be created from the form

  • Call a new Server API called ConfirmENSNameBeforeCreating

  • Extract the name from the response

  • Display a confirmation dialog box

  • If yes is clicked, then create the object

The server required a new Server API to be written and an override of OnCreating on one of the realized interfaces from DEVENSClass1 ClassDef.

An explanation of the create server process is required to explain how this works.

The server processes the XML sent from the client. In this case it builds an object that represents an instantiated version of DEVENSClass1 ClassDef. Any properties entered on the create form are filled in along with the IObject properties like creation date, and so on. All required interfaces are added and required properties. Because the ENS definition can use properties from related objects, we can't build the ENS definition for the new object until everything is ready to be sent (committed) to the database. At the point of commit we fire MethodDefs on the object, which can be overridden at each interface.

In this example DEVENSClass1 has a primary interface of IDEVENSClass1 and realizes IObject. So to get this to work I had to introduce an existing interface into its class definition. This is because there was no code generated for the primary interface, and at the time it was easier to just change the structure. We chose to realize ISPFAdminItem and made it required so we could guarantee it would be present on the object. The reason we chose ISPFAdminItem was because we knew that we could use the sideways override (ISPFAdminItemDefault1) to change the behavior.

Now we have an override of ISPFAdminItem and we know that the OnCreating MethodDef is called just before everything goes to the database. The purpose of the MethodDef is to give the developer a chance to cancel the transaction. This is perfect for what we wanted to do, so we added an override that cancelled everything if the class definition is DEVENSClass1, and the Server API that originally started the transaction is our new Server API.

Now the create is cancelled, and the name has been generated so we need to extract it and send it back to the client. This meant work in our new Server API, so the code was copied from the original Server API, and in the exception handling of OnHandlerBody it looks at the CreatedObjects property on the LoadReport object and extracts the name. The OnSerialize Server API method then sends the name back to the client.