Beginners Guide to the CA Plex Model API using C# .NET

Firstly thank you to Rob Layzell for inspiring this blog.   If it wasn’t for his lab exercises I would have done this Model API exercise and subsequent blog using CA Plex and component import.  Now, whilst this is probably a cool thing using a code generation tool to interrogate and update the code generation tool repository (I am sure there must be a word in the OO world to describe this. JJJ).  In the back of my mind I was also acutely aware that release 7.0 is entering beta testing and the much anticipated C#.NET (WPF) client will soon be upon us.  So there isn’t a better opportunity for me to sharpen the old grey matter with some learning than this. 

I chose to continue with the C# coding for the simple reason that it would be worthwhile me understanding what .NET developers need to do as I will ultimately be looking to target .NET for my future applications.  And, of course, enable me an opportunity to learn Visual Studio, some pigeon C# and understand the inner workings of this environment.  All worthwhile skills for when the 4GL needs a little investigation, tweaking or debuggingJ.

We have had C# for server code generation since release 6.0.  Release 6.1 brought WCF to strengthen this offering.  With 7.0 we will have the client side resolved too with the promise of XAML and WPF.  The web service import is another tool that simplifies the integration and consumption of web services, so, all in all, good times ahead.

So back to Rob's unintended blog influence.  His tutorials for .NET used numerous examples of Visual Studio and C#.NET.  One in particular that took my fancy was Lab 10 and related to consuming the PlexAPI COM component and creating triples in the local model.  The ModelAPI is described as being useful for pattern designers in the online help in order for them to automate much of the configuration and setup for using their patterns.  I also see it as an opportunity to ensure that another level of automation is included in the tool.

Anyhow, seasoned CA Plex developers know we already have metacode to influence the generated code.  We also have patterns and inheritance to ensure consistent design or as I call it, conformity to the application architecture.  There are still of course plenty of areas with regard to modelling that a developer could easily get wrong when entering the triples.

In my last blog I alluded to a small entity creation tool that I am creating (UPDATE – This has blown into a full blown too now).  This is to ensure that the fields and files that I enter into the application model conform to our standards i.e. naming, inheritance, default field lengths, narrative being entered and labels etc.  As we are a new CA Plex (long time 2E shop) I am still working on these standards and experimenting but I will share the code and a sample model on request (note that this does currently have a degree of hardcoding at the moment but more than enough detail for people to get acquainted).

For those that are interested in taking this further and perhaps helping me improve the utility, just drop me your email in the comments section. J

For me this (ModelAPI) is too quickly overlooked but if you are serious about CA Plex and modelling then these are exactly the type of utilities (Add-Ins) that one should be considering.  These will further improve your team’s productivity as it is pretty quick and easy to tailor for your environment once you get your head around the API and the underlying model structure.  Just take a look at the StellaTools from George.

I recommend any CA Plex developer to take some time to understand what you can achieve with this feature.  This is quite an in depth subject so I feel that this will eventually become a four part series, so, if you are keen....

Part II – ‘Model API and the model repository’ will cover the underlying architecture of the model.

Part III – ‘Key Model API commands’ will go into detail about some of the core commands that you will need to understand in order to develop against the COM API and sow some of the theory covered in part II together.

Part IV – ‘Some DotNet Tips and Tricks’ will show some programming tips and I hope should be enough to inspire a few of you to ‘RTFM’ with regard to the Model API.

All feedback is appreciated.  Until then.

Thanks for reading.
Lee.