I don’t use the Schema Editor for schema changes to SPF; I hand-code the updates in XMLSpy. This is pretty straightforward when modelling the more common objects like Classes, Interfaces and Properties. But Graph and View definitions are a little trickier.<\/p>\n
I deconstructed some existing Graph and View definitions in order to create some new ones manually;\u00a0this blog shows what I learned. In this explanation I gloss over the usual stuff like relationships between the objects; it’s the syntax of the definition strings that I go into detail on. This is based on SPF 4.3.3.<\/p>\n
<\/p>\n
To make a new Graph or View (or any Schema object), I just find one similar to the one I want to create, do an Export Data on it, expand all the relationships it has, copy the whole set of XML elements out to my text editor, wrap it in a <Container>…<\/Container> root element, then start changing each element to be what my new one needs. When done I load it with the Schema Import Wizard and test it.<\/p>\n
Think of a DirectedGraphDef as a set of related objects from a starting object. For example, starting from a transmittal object, a Graph that identifies all the files to be extracted to a ZIP file might identify the files found at the relationship path: Transmittal > Document Revision > Latest Document Version > Files, and also the files at: Transmittal > Files (those attached directly to the transmittal). A Graph might start from one object, or it might start from a collection or set of multiple objects. The Graph does not identify any specific properties of the objects it identifies; it merely gathers the objects up,\u00a0and assigns names to them, so they can be referenced from other paths in the Graph, or ultimately\u00a0from a ViewDef.<\/p>\n
Start by defining the basic properties of the DirectedGraphDef like Name, Description, etc. Next define a relationship from this DirectedGraphDef to the InterfaceDef for the object it will “start” from. Use the Export Data XML of an existing example to see how to set this up and what type of relationship to create.<\/p>\n
Now comes the fun part. \ud83d\ude42<\/p>\n
The property GraphDefn<\/strong> is the main property for a GraphDef. A typical value looks like this: (newlines added for readability at the commas, normally it is one continuous string)<\/p>\n It has the following syntax:<\/p>\n The components that are separated by slashes are, in order (these names are made up by me, so may not agree with what Intergraph’s Schema Editor calls them):<\/p>\n So each string between commas looks like this:<\/p>\n Unique ID<\/strong> is either a relationship path in the form RelDef_12, or EDG_EdgeDef to refer to an EdgeDef already defined in your SPF schema. Where it ends, the objects at that end will be the “selected objects”.<\/p>\n Name<\/strong> is an English name given to the objects selected by the Unique ID path.<\/p>\n Start From Name<\/strong> is optional, if not specified then you still need the leading \/ slash character. It refers to a previously-defined Name value in a prior string in this Graph. If specified, it means the Unique ID “relationship hop” path will start from<\/em> that set of objects, not the original Interface for the Graph.<\/p>\n So in this example:<\/p>\n If Graphs gather up and assign names to the objects related to a given starting object, then ViewDefs identify the properties to be extracted from those objects, for use in a report, for example; and assigns names and categories to those properties for ease of reference.<\/p>\n ViewDefs can be used directly by users when they select File \u2013 New \u2013 Report. The initial list displayed is a list of ViewDefs they have access to through an access group (below).<\/p>\n Like a DirectedGraphDef , ViewDefs require a relationship to a starting interface. They also require a relationship to a Group to allow access to use them, like a Method.<\/p>\n ViewDefs\u00a0also need a DirectedGraphDef. This is not a relationship, rather the name of the DirectedGraphDef is stored in a property value. Certain values in the property string ViewPropsDefn (discussed below)refer to the “Name” components in the Graph’s string.<\/p>\n The property ViewPropsDefn<\/strong> is the main definition of the ViewDef. A typical value looks like this: (newlines added for readability, normally it is one big string)<\/p>\n It has the following syntax:<\/p>\n Components of each string are:<\/p>\n So each string between commas looks like this:<\/p>\n Graph Edge Name<\/strong> refers to the Name component (middle part between two \/slashes\/) of one of the GraphDef strings. This selects the objects to read property values from.<\/p>\n Interface<\/strong> is the name of the interface on those objects to get read property values from.<\/p>\n Property<\/strong> is the name of the property to read values from on the selected objects.<\/p>\n Name<\/strong> is the display name given to those properties.<\/p>\n Category<\/strong> is a heading under which this Name will be grouped.<\/p>\n Number<\/strong> is a sequential number, must go up by 1 for each string. The highest vaule must also be put in the property LastLocalID.<\/p>\n So in this example ViewDef (assuming it has a relationship back to the example graphDef above):<\/p>\n <\/p>\n Those are the key tricky bits I found to Graph and View definitions in SPF. Now you can create a report that uses the View Definition.<\/p>\n Next I plan to blog on how to create an HTML transmittal report (ie. cover page) using XSLT using Graph and View defs like those above.<\/p>\n Please comment if you found this post useful.<\/p>\n","protected":false},"excerpt":{"rendered":" I don’t use the Schema Editor for schema changes to SPF; I hand-code the updates in XMLSpy. This is pretty straightforward when modelling the more common objects like Classes, Interfaces and Properties. But Graph and View definitions are a little trickier. I deconstructed some existing Graph and View definitions in order to create some new […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[6,5],"tags":[3,4],"class_list":["post-7","post","type-post","status-publish","format-standard","hentry","category-schema","category-smartplant-foundation-spf","tag-directedgraphdef","tag-viewdef"],"jetpack_featured_media_url":"","jetpack_likes_enabled":true,"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/posts\/7","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/comments?post=7"}],"version-history":[{"count":14,"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/posts\/7\/revisions"}],"predecessor-version":[{"id":55,"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/posts\/7\/revisions\/55"}],"wp:attachment":[{"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/media?parent=7"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/categories?post=7"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wolfcreekconsulting.com\/blog\/wp-json\/wp\/v2\/tags?post=7"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}+ITag\/+ITag\/,\r\nTagDocument_12\/DocumentVersions\/+ITag,\r\nSPFFileComposition_21\/Files\/DocumentVersions<\/pre>\n
\n
\n
\n
\n
\n
ViewDefs<\/h1>\n
+ITag\/IObject\/Name\/Name\/Identification\/1,\r\n+ITag\/IObject\/Description\/Description\/Identification\/2,\r\nDocumentVersions\/ISPFDocumentVersion\/SPFIssueDate\/Issue Date\/Identification\/3,\r\nFiles\/ISPFBusinessFile\/SPFLocalFileName\/Local File Name\/Vault Info\/4<\/pre>\n
\n
\n
\n
\n
\n
\n