If you read the first of series of 3 blog posts reviewing the Capital Application Programming Interface or API you got to refresh your knowledge of what motivates software vendors to add interfacing and extending capabilities to the many features already provided. In the prior blog, there was emphasis on the benefits which you and your company can get from using the API. Now you are plugged-in about plug-ins, so to speak, the remaining information I want to share with you will tune-up your understanding of the API. I’m inviting you in the last in the series, to look again at the features and further into what you can achieve.
What is the difference between an API and configurability?
An API definition I like is “a set of arrangements which allow you to create predictable interactions with internal data storage and other systems’ and to extend the baseline functionality of an application”. Configurability is a set of user interfaces with the aim of modifying the behavior in some part of the application.
So an example in Capital of the API would be the using it to select cable ties for a bundle by crafting a plug-in for the BOM processing steps activated on the Harness Design. The plug-in delivers what you want to put in it to meet your own requirements. Keeping with this example to look at configurability – the Capital Harness XC processing step which calculates out the diameter of the bundle to which the strap will be fastened uses input parameters which can be adjusted. In the Capital Project System preferences you have three alternatives to one called “basic default” to choose from. And just to make things interesting one of the four configuration values refers to another configuration field which you can set to a value of your choice.
There’s a hierarchy of effects. If you choose different configuration values, the inputs to your plugins can be changed. If you change the plugin, the configuration of Capital’s standard functional behaviors remains as it was.
one of many possible customer configuration preferences in the Capital application
Will it be justifiable to use the API even though there’s no ambition to do Web Services Based Integration?
Even in the largest Capital Installations customers tend not to make frequent use of Web Services compared to other API implementations. But many do something. 10% of API users’ time seems about average in the customer base from what I have seen of the total time spent making API extensions related to data exchanges and systems integrations using Web Services frameworks . Customers are reporting significant process benefits from doing so. Nevertheless majority of time goes into API customizations for daily use in another sense. That is the augmenting of the user experience with diagram and design data validation and automation – custom Design Rule Checks are an example and the commonest use of the API.
If there’s no intention to use Web Services for integrations at the moment, that is perfectly fine. The functionality – the web service hooks are there if you need them in the future. And there is undoubtedly still to be taken – all the benefits of validations, design rule checks, processing extensions for import/export and the many other things that Capital customers value in their daily work empowered by the API. The set of API resources includes more than 500 java classes. It would be remarkable if a customer used every one. Not using some API features is perfectly normal.
Upgrades and Version Changes – compatibility non-issues.
Mentor Graphics have paid close attention to what users want and don’t want. It is considered wasteful and unwelcome transitioning to another version of a business application to have to go through arrangements to migrate the custom utilities, the code extensions.
Mentor has taken every precaution to make sure you don’t have to do that. When you apply a new version of Capital, your user acceptance testing of the software release is pretty much always going to find that code written in the API carries over to the newer version and works in exactly the same way it did in the old version.
Notice I did not say “always” using instead “pretty much always.”.I have only ever heard of source code on two occasions having to be revised. Two code extensibility objects out of many thousands of code objects re-used in later versions have gone to the later versions as customers explore the annual improvement in functionality. Those rarities are reasons it is vital to do acceptance testing, however they are in the case of the API extremely rare. You should not expect them to happen.
Some lesser-known aspects of the API.
The manufacturing tools for labor cost estimation and sub-assembly determination are also covered by the Capital API.
You can define template functions for your Structured Bill of Materials patterns for production module definition and cost calculation use in Capital manufacturing multi-level bill of material analysis. Capital MPM Capital TVM include this facility.
Augmentation via a plug-in written in the API can be rare, but sometimes essential needs.
There seems to be often at least two, sometimes three or four methods of doing some things in Capital. That’s the blessing of being functionally rich. Which method of alternatives will work for you, well, that depends. It depends on your requirements. With flexibility comes responsibility to make good informed choices, a need also to gain an understanding of the configuration controls of the software.
For example, a styling condition to be visible or invisible can be predicated on a stored system query, or if the query language provided proves insufficient – and usually it is fine – then you can do something more complex with a plugin. Perhaps the extra step is to read some information from a non-Capital external source for instance. Then you would need to write a plugin.
Style set definition can entail use of a plugin for special requirements
I was talking with a product manager of another software company recently who gave the opinion that where customers ask for an enhancement in that software it was over 95% of the time a case of having missed some base functionality which is available. Mentor’s Capital customers don’t experience this as often, because the support documentation and training is very comprehensive and backed up with real human experts. And then there is more configurability. And after configuration then there is the possibility of making custom queries and if you are still not satisfying your requirements then you can write a plugin if needed.
Creating a query or re-using one you have already defined is a step in making diagram appearances conditional according to special business rules.
Scoping of library items’ using Capital Enterprise Assets can be defined using custom plug-ins.
Applying a component scope to library items is a technique of designating approvals for inclusion/exclusion on differentiated projects or at distinguishable locations, or with different customers. This is normally done by setting data tags against items in the library, and normally the maintenance user interface provided is sufficient to Capital Library users’ needs. Where there is another step the software needs to go, the API allows that individualized processing. There is flexibility to change the part choices and harness processing selection parameters which may differ between projects, customers or manufacturing sites by writing their own plugins.
The API is akin to a “last court of appeal” sometimes if you want pliability in software functions which you cannot find in standard menu options.
Though the Application Programming Interface has been enhanced, it is extremely unlikely that it will be substantially changed.
Continuity in the way you integrate between your enterprise systems and Capital is something Mentor Graphics recognizes is important to you. Once set up it becomes costly/risky to change. So stability is important, and just like the attention given to making the forward compatibility of code – priority is given to expanding capabilities. Mentor Graphics recognizes the aspirations of customers to preserve their investment in their private extensions to Capital tools because it is giving daily benefits.
Democratizing Capital reporting: API functions may be devolved to end users.
As the API has grown up it has become more generous. Functionality is lately disseminated into the Capital user interface of standard users which formerly was available only to system administrator types. If system administration types are happy for you to do so, you may see in the 2014.1 version and later a report builder. There is a simple user interface which will generate plugin code into the common area for extensions.
Think up some better names for your plugin code than this when you use the Report Builder
Summary.
Remember, the detail is important. The detail is everything, but to finish here’s a summary of what the API puts in touching distance.
- Systems Interconnections and integrations with your other enterprise class software suites
- Automating repetitive tasks specific to your business or workflow which the off-the-shelf functionality does not cover
- Special Reporting – management summaries, business intelligence data extracts for example to dashboard type supervision and control applications.
- Augmentation of Capital standard validations with process- or customer-specific design checking with individual business rules.
- Methods to achieve data processing task scheduling and events triggering publishing of data sets (exports/print packages).
- Extension of processing algorithms with intellectual property private to your own organization.
No need to be careful in wishing for these things. Wish away but stop soon and take some action, mobilize some resources and start to get the benefits.