Beginners Guide to the CA Plex Model API using C# .NET - Part II - 'Model API and the model repository'

The first post in this series late last year touched on the power of the Model API and how it could be useful for us Plexxers out there. 

http://www.leedare-plex2e.blogspot.co.nz/2011/10/beginners-guide-to-ca-plex-model-api.html

I envisage us automating trivial tasks, extracting information from a model, import system designs into CA Plex, integrate the IDE with other environments/tools as well as code generation productivity tools like my Entity Creator!!!!!

Today we will cover some of the theory, Part III will highlight some of the core methods that you can use to interrogate/update the model and finally Part IV will show you a basic example in C#.NET (DotNet) and give you some other little tips and tricks along the way.

We all know what the Model API is, “don't we!”, but just in case here is my take on it.  Put simply, it is a gateway, interface, framework for interacting with your CA Plex environment and your local model(s) and it is implemented as a COM API.  CA ships a great local model and plenty of documentation to get you going and Google will reveal numerous posts from community members in our forums.

So let's get started.  To truly get the Model API and how it works you need to remind yourself of the underlying repository that CA Plex uses.  A great place to start is with the 'Model Editor' and understanding its design layout.  The ‘Model Editor’ is probably one of the most used editors and with a good understanding of how this triple store works you are set up for Model API programming and Meta Coding techniques also .

Fig 1. Below shows the CA Plex Model Editor focused on a field object FIELDS/YesNo which is a basic single byte status field with a couple of values that is shipped as part of the CA Plex patterns.

The next couple of images might be a bit patronising for the long term CA Plex user so apologies if the next minute of your life is repeating what you already know.

You will see that the model editor has three distinct columns.  Column A is the Source Object column in CA Plex terms, Column C indicates the Target Object and Column B contains the linking Verb that help describes the relationship between the two objects.  Collectively this line is known as a Triple, multiples of these are known affectionately as Triples and they reside in the Triple Store.

Above this area highlighted in yellow below are fields that tell you what the source and target objects are.   This is the Object Type.  i.e. Entity, Field, Table, Interface etc.

So let’s transpose this knowledge onto Fig 1.

Column A (Red) = Source Object(s)
Column B (Red) = Verb
Column C (Red) = Target Object(s)
Object Types (Yellow)
Triple (Blue)

Let’s recap, key learning items for Model API terminology are Source Object, Target Object, Verb, Triple and Object Type and these will be referred to throughout this series of posts.

Back to the Model Editor

We know that the Model Editor can show you all triples for a Source Object and defaults to one level.  All the triples at this level are known as real i.e. they are implicit and not inherited.  If you show the object properties for the field FIELDS/YesNo you will see this clearly in the Object Properties window.  This is a key reference window when using the Model API and is your friend, trust me.

The other three properties that are NOT real are of course inherited.  As inheritance is defined using the ‘Is A’ verb, in this case FIELDS/YesNo – FLD Is a FLD – FIELDS Status.  YesNo inherits from the FIELDS/Status field. 

Double click the Target Object FIELDS/Status in the Model Editor and you will see the inherited triples mostly relate to the details in the Object Properties window.  There is a small exception with the Control SYS triple which is a bug/feature/design consideration but I will leave that out of scope for this post, just note that it is there.

Generally speaking if a triple is repeated or overridden at a higher level it (the implicit triple) takes precedence over the inherited triple and therefore they are not shown.  i.e. The Limits SYS (All) triple only shows at level 1 but in fact it is entered at both Level 1 (FIELDS/YesNo) and Level 2 (FIELDS/Status).

The rest is just about understanding how to traverse through objects and related triples in the model.  There are also lots of other cool API methods to help with automation.

Post III will go into more detail about the methods that are available within the Model API with a focus on traversing the Model Editor and its triples.  Hopefully, introducing the concepts above will help you succeed.

Thanks for reading.

Lee.