User Tools
toolsandtechnologies:best_practices
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| toolsandtechnologies:best_practices [2020/03/05 14:50] – akavanagh | toolsandtechnologies:best_practices [2021/06/25 10:09] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== RDF Agent General Guidelines & Best Practices ====== | ||
| + | * Before integrating new technologies, | ||
| + | * Your choice of protocol should be guided by a number of factors, but the main important aspects are: | ||
| + | * Allow for the determination of an appropriate ne name of each network element so that traps can be correctly associated with the discovered elements. | ||
| + | * Determining an appropriate discovered name value for every network element which can be used for other discovery operations such as alarm sync, configuration and performance. | ||
| + | * Consider the performance aspects of your implementation, | ||
| + | * Sometimes you have no choice but to use a particular protocol as the information you need is only available that way. | ||
| + | * The choices you make in these early stages are important to try to get right as all future fixes and updates to your processor are limited to this implementation unless the decision is taken to re-write the discovery process to use a different protocol or collect and parse data a different way. This is a time-consuming process so a little time spent coming to the correct decision at the start of the implementation can save a lot of future headaches. | ||
| + | * The new RDF has a wide range of different protocols supported compared to the old RDF which just had 2 - SNMP, HTTP and database. Having a lot more choice in how you can discover data gives you more options to collect data in the correct way with best-suited information. | ||
| + | * It will be tempting to make changes to an existing Processor class, especially when new versions of remote devices become on-line in production. | ||
| + | * If this is not possible, for example, a new device version cannot be supported correctly in an existing processor class without breaking older versions, you can make a new processor for this version. Make use of the 'is compatible' | ||
| + | * When creating processors you are doing so in an active code which is shared with other developers and operations engineers. Like with any code project, the goal when writing code is to have it as clean and concise as possible. Readability is very important if someone has to update your code it is extremely helpful if the code speaks for itself and everyone understands what the code is trying to achieve. If some obscure code is unavoidable, | ||
| + | * Currently there are no defined templates on how to structure processor class e.g with helper methods etc we hope to in the future. | ||
| + | * If you find yourself repeating code then make sure there is not already a helper class for it considering creating one. | ||
| + | * If a helper class is there but it does not account for this, consider adding your own reusable code to the helper class if it will benefit others. | ||
| + | * Currently, the guideline is to make a single java class per version range which implements all the discovery interfaces which are supported for that device and version range. | ||
| + | * Packages in the RDF Agent structure should correspond to the device technology e.g com.errigal.rdf.processing.technology.CombaFlexMBDA | ||
| + | * Please do not update or change any of the core classes outside of the technology package. At this current moment in time, there should be no need to update any of the classes outside of this package. From a processor implementation point of view, everything you need should be readily available and to hand. | ||
| + | * As the RDF Agent is a new application, | ||
Page Tools
