The guidance that I can provide below is solely intended for importing connection information into Fiber Manager during the initial phase of the project. We do not support interacting with the connections directly after the system goes live.
The key fields for importing connection information are as follows:
Field Model Name Description ACLASSMODELNAME The class model name for the A-side object of the connection ACONNECTIONOBJECTGLOBALID The GUID for the A-side object of the connection BCLASSMODELNAME The class model name for the B-side object of the connection BCONNECTIONOBJECTGLOBALID The GUID for the B-side object of the connection GLOBALID The GUID of the connection object itself. CONTAINERCLASSMODELNAME The class model name of the container object for this connection. This has to be a feature (with geometry) and is usually a splice case or patch location. This information is critical for the proper functioning of the software. Without it, connection manager would have not way of knowing what connections are contained at each location. CONTAINERGLOBALID The GUID of the container object for this connection. SPLICETYPE The type of connection. This is usually controlled by a coded domain. Note that we create "continuous" connections when cables go through splice cases but no physical connections exist. This is important for our current tracing logic as it will not pick-up splices cases along a trace unless there is a connection. Without this information, when tracing, you will likely get an over-simplified result and will not be able to see any of the splice cases your cable is going through.
So, for each connection, you would have to find the corresponding model name and GUID for both side (those are typically strands, connected to ports, either on patch panels or devices). Then, for each of those connections you would have to provide the container. If either of the side of the connection is a port, this is pretty straightforward as you can just walk up the hierarchy until you hit the feature it is related to. For strand-to-strand connections, you will need to know the container via some other way. If you are importing, you want to make sure you have that information up-front.
Other fields are more optional and will depend on your implementation:
Field Model Name Description ATTENUATIONAFREQ Attenuation value in db for the first frequency (A) ATTENUATIONBFREQ Attenuation value in db for the second frequency (B) TRAYNUMBER The tray number (in a splice case) where the connection is located.
For the record, we have several partners who already specialize in importing fiber data into Fiber Manager (Ed Blair, Skye Perry) and depending on the project, this is usually something that is performed by our Client Services team. I strongly recommend you contact them or your account manager (Dave Magee) with specifics about your project. Data quality is extremely important to the proper functioning of Fiber Manager.
Thanks for the information about FiberConnectionObject table.
We have a live Fiber Manager system on which we digitize the fiber roll out.
We were thinking on ways to speed up the digitization process, especially of the long haul fiber cables. The splicing is pretty straight forward one to one connectivity.
I thought about fiddling with the FiberConnectionObject table, but was apprehensive due to lack of API support and its impact on the system.
We will do some test on our development systems and will share the results. An API for managing fiber network connections will be most definitely appreciated.
On your long haul cables, digitize the entire length of cable first. Subsequently, go in and digitize your splices. The splices will do two things: split the cable and do the 1:1 connections that you discuss. This may save a step.
Could you manage to automate the connectivity in Connection Manager. If yes, can you please throw some light on the API.
Thanks & Regards,
No, its a project currently shelved. But will surely start it after sometime.