Unsolved
This post is more than 5 years old
2 Posts
0
4601
EMC Smarts SDK status
HI all,
This is my first post so bear with me my in-experience.
I'm relatively new to the EMC Smarts product suite. However, I've been attending discussions throughout the year identifying gaps in our monitoring setup.
My questions are:
Does EMC continue to support the SDK? The documentation refers to version 6.5.1 dated 2006.
How about integration. EMC Smarts integrates with a number of management systems via adapters (e.g. sm_ehealth). I believe these are categorized as custom adapters. Is the SDK not used to build custom adapters?
Finally, I'm trying to gather all the necessary documentation to tackle the possibility of building adapters. So far the documentation I've uncovered are:
EMC Smarts Adapter for Concord eHealth 1.2 (P/N 300-003-280)
EMC Smarts Adapters Event-to-Notification Templates 1.0 (P/N 300-006-937)
EMC Smarts Software Development Kit Remote Programmer's Guide 6.5.1 (P/N 300-003-309)
So my understanding is, an adapter (e.g. sm_ehealth) needs to interface with the Adapter Platform Suite to convert events to notifications. Topology is built within the adapter and gets "uploaded" to the Adapter Platform. The 3rd party application needs to be able to export it's configuration and the adapter must be able to parse the configuration. The adapter also builds the topology and makes the event to notification association. When a trap arrives to INCHARGE-OI, the trap manager understands how to tie the trap to the proper object (in the repository).
Thanks for any advice you can provide.
Dennis.
Berkay1
36 Posts
1
December 14th, 2009 05:00
Hi Dennis,
I'd say SDK is not really supported. As you've noticed, it has not been updated for a long time. However, SDK is not required for integrations with other systems. Rather it is typicaly used to build new domain managers. For example if you wanted to build a Smarts domain manager to build GSM networks, etc.
Smarts (ASL, Java and Perl) APIs to work with Smarts repository (and may be Smarts dynamic model feature) are all you need to integrate other tools with Smarts.
There are different levels of integration. If you want to just create notifications in Smarts from other system that can send SNMP traps, you can simply configure the trap adapter to process those traps. However life is often not that simple.
EMC provides an ASL based adapter framework that they internally use to build adapters. ASL has full access to Smarts repository and if you invest in learning it, it's a powerful tool. It's shortcoming is that it has little to no capabilities to work with external systems, hence if you want to integrate with external system via ASL, you often have to get the data out of the system first into a file, etc. Adapters internally build by EMC overcomes this shortcoming in some cases, but you'll find little to no documentation on how this is done, other than the adapter code itself.
When sophisticated integration is required, use of remote APIs (Perl/Java) is a much better option as you can interact both with Smarts domains and external systems. Unfortunately support for the use of APIs by EMC is quite poor as well. You can hardly find any official information other than basic documents. Smarts Remote API document that talks about Java API has not been updated for many years, and Perl reference API is best you get.
We use Smarts Java API for all integration work with Smarts and it works well. Java API is used by the Smarts Global console so at least you can have some confidence that the problems would be attended by EMC. I have much less confidence with Perl API.
In short, you need to first get familiar with Smarts repository classes, properties, relations, and operations, and learn how to use the APIs to work with the Smarts repository to do anything sophisticated.
Hope this helps, feel free to ping me if you have any questions.
Regards,
Berkay Mollamustafaogluhttp://www.ifountain.com
Ph: +1 (571) 766-6292
mberkay on yahoo, google and skype
dchang2012
2 Posts
0
January 8th, 2010 08:00
Hi Barkay,
Thank you for your response. It was most helpful.
Reading through the documentation can be difficult because, it's my feeling that the use of the word "adapter" can be misinterpreted.
For instance the use of the word "custom adapter" is mentioned once as a means of interacting with the "adapter platform, i.e. INCHARGE-OI.
The other means are, sm_ems, syslog adapter, xml adapter. (The word "custom adapter" is mentioned in the first few pages of the "adapter platform" document). The problem is that they don't make any mention of it afterwards. So I'm alittle confused. Plus the fact that *ALL* asl scripts/hookscripts are considered adapters! So that would include Perl as well. Anyway, you get my meaning.
What I'm interested in is the sm_ehealth adapter. I believe this is an example of a "custom adapter".
And the way that it's described in the documentation can be re-worked and applied to other monitoring tools. So for example if I have a monitoring tool A which has an XML configuration output. Then, technically I should be able to build a topology with this output and finally interpret the traps received from this monitoring tool to the topology object that I created. So what I want to do is build another "custom adapter".
Any comment?
Thanks,
Dennis.
Berkay1
36 Posts
0
January 8th, 2010 11:00
You can certainly sort of reverse engineer the sm_ehealth adapter to understand how it works and use it as a base to create other adapters.
Is this the right way to go about it? Personally I don't think so but I suppose it depends on what skill you have, what you're actually trying to accomplish and what constraints you have. If you're well versed with ASL then what you're planning may be a viable option for you. Otherwise I'd go with Perl/Java API.
I'd start with laying out what the purpose of the adapter is, and then determine what the best way may be to build the adapter. The requirements of your adapter may dictate which approach you should choose.
Just my 1.5 cents...
Berkay