Idea Details

Web based Spectrum

Last activity 06-13-2019 09:49 AM
Anon Anon's profile image
08-31-2014 11:51 AM

I'd love to see the day when Spectrum can get rid of the Java client requirements and be web based.  This would make rolling out Spectrum much more easier. When one is trying to access the SpectroSever from linux, mac, and Windows clients having to deal with the Java JCE file is a real pain.


Comments

01-16-2016 04:50 PM

Stuart, thanks my friend, this means a lot! I know we have come a long way, but do plan to be at CAW 2016 - we intend to take things to the next level


Regards,Kiran Diwakar

01-14-2016 12:20 PM

Yeah.  It showed up on the Download Products page this morning.

01-14-2016 12:08 PM

I was joking :-) nah we have a project to go to 10.1 and your right we can collapse up to 11 into one, plus now talking about 2M models, that is real scalability.

01-14-2016 12:06 PM

01-14-2016 12:04 PM

Scalability of 10.0 is freakin' awesome. We went from 7 SS to 1 SS. Can't wait for 10.1. Worth going to 9.3 then immediately going to 10.0. Solved a bunch of our cross-landscape headaches.

01-14-2016 11:54 AM

I am just looking to upgrade to 9.3, what is 10.1 you speak of :-)

01-14-2016 11:52 AM

Has 10.1 gone GA yet? I hadn't seen any announcements.

01-14-2016 06:35 AM

Folks,

 

The idea is delivered as part of CA Spectrum 10.1 release.

 

Thanks,

Nagesh

08-06-2015 12:59 PM

Folks,

 

Don't miss the Sneak-Peek/Teaser post by Kiran Diwakar . Here is the link: Re: Spectrum August WebCast - Sneak-Peek/Teaser

 

Thanks,

Nagesh

06-09-2015 12:44 PM

Folks,

 

This idea is lined up and planned for future releases of CA Spectrum.

 

Thanks,

Nagesh

03-18-2015 10:04 AM

Hello Frank, Team,

 

I am doing a WebCast for 10.0 features and demo in a few weeks and I will also be touching things we intend to do in the coming releases.

Will be covering this web based Spectrum for operators, as I had talked about and will share details of the requirements we are targeting.
Please do plan to attend..

 

Regards,

Kiran Diwakar

03-18-2015 09:00 AM

I agree, I can't wait to get rid of Java! I think it is good in terms of being able to run same code on different platforms, but HTML5 can do that now too, and Java is just very slow and very bulky. HTML5 all the way!

03-13-2015 03:58 AM

I have build our own bi-directional integration layer into Remedy with notifier, mysql, & arsperl.  I would also like to upgrade the spectrum to sql integration from using the notifier to using web services. 

  • Since we had all the information in a DB, I built a custom web interface for our operators to ack, manage and admin INC's, with custom reporting to the shift manager, all with standby reporting and contacts integration.  Each alarm from this web interface can be drilled down into Spectrum or Remedy.
  • For devices outside our data center, I integrated GPS co-ordinates from another DB, and then plotted the INC's on a google map, again web based.  The INC's are updated real time, but the web gui reloads every minute, which on a helpdesk, is good enough.
  • I also store the contact_status for each device to create my own heat maps based on location, with history for 2 weeks to analyse trends (Africa, used ed, stable power and networking aren't synonym).  These location pages also contains links to Spectrum, the ehealth port Live report, and alarm history.
  • The cherry on the cake is that our IT Director had an app created (running on HTML5) to show INC's in grabs from our integration DB, with all the nice details contained.


As for the Java gripes, this is the one serious issue that can't be resolved quickly enough!!

02-15-2015 10:58 PM

This is EXACTLY what we are looking for.  Currently we have to deploy Orion and Spectrum together because there is no web-based Spectrum capabilities for the RO Operators Group.

02-15-2015 10:52 PM

Hi Erich,

 

I was smiling all through as I was reading your response - It is almost like you are stealing my thunder

The reason is, I am thinking a lot on lines of what you have - my thought process/theme around this is "Separate Monitoring from Administration"

I was planning to do this in the new FY, but since you raised that topic, let me share what I am asking the engineering team look at from a feasibility and cost perspective. I have talked to more than a dozen of our large customers on this and it resonates well with them. Please see below and comment...

 

---

 

   Separate Monitoring from Administration

Monitoring is mostly read/view only operations that revolve around alarm/events and triage of those situations – typically done by operators, whose numbers in most deployments could range from 10s to 100s

Administration is the configuration aspects of the tool itself – Spectrum in this case – typically done by administrators, whose numbers in most cases range from 0.5 to 5

The philosophy would be to let administrators continue to use the Java OC Client and the operators can then be shown the Web Based View of Spectrum to do the following:

  1. Alarm and Event View (replicate the events tab from OC as much as possible)
    1. Ability to see GCs & ability to select alarm/event on right hand pane, with details of the alarm like
      1. Alarm type, severity, probable cause, root case, impacted devices etc
      2. Try to replicate as much information as possible from events tab
  2. Ability to acknowledge, clear, open ticket for the alarm and other key operations
  3. Basic diagnostic capabilities for device on which alarm is asserted (ping, poll, traceroute etc)
  4. Ability to get “Alarm Filters” and show alarms per the filter
  5. Ability to show as an optional/configurable item a Java applet, which shows topology in context of the alarm selected for the device
    1. The reason to show it configurable is because this brings in Java dependency and could have performance implications in some scenarios and hence make it configurable in the first iteration for whoever can benefit from using it and later based on response think of other mechanisms

----

 

As I mentioned, this is a "thought process" and initial set of requirements/ideas that i have, that we want to try and get to fruition - and we are trying to deal with the daily activities/escalations et al - to try and get some bandwidth to have someone look at this seriously and hence we cannot say "we will do it by x" - but I would like to assure you and all, that we are very serious to try and get this atleast "moving" as much as possible.

 

As always, comments and critique very welcome.

 

Regards,

Kiran Diwakar

02-15-2015 11:42 AM

Hi Kiran,

the existing topology-Applet is only a gimmick, - nice to have but in the past 4 years, I havn´t it seen at any customer-installation.

Most Spectrum-USers are "Readonly"-Users or Users with the Role "Operator-RW" .. to be able to assigne and acknowledge alerts.

 

For a good start, we need a Navigation-tree from the left side of the Oneclick-Client and the ability to view the alerts of global collections.

Therefor we need the ability to povide a HTML-GUI where an Operator-RW could work with.

 

If it is to complex to implement a topology-view, then replace it first with a neighbour-view which could be a tabular view.

I have seen many people building different HTML(5)-Clients for Spectrum to be able to view alerts and acknowledge alerts.

 

Form my perspective as a Spectrum-SE and consultant, CA should follow the strategy of other vendors.

1. Identify the minimum requirements to provide a mostly "readonly"-access for a mass of users

2. Implement an REST or SOAP-API which could provide the data for this client (

.. with the REST-API of Spectrum it is a hard job to get the alerts or the status of an Global Collection. Its hard to fetch the neighbors of an model, because the neighbor-view is defined by the IP-Adress as Input-Value and not the Model-Handle. Finally, there are many gaps in the REST-API.

3. Implement a HTML(5)-Client with a good supported HTML5-Toolkit .. Support for MSIE, Firefox and Chrome are needed.

 

Perhaps admins could use the fat-oneclick-client for a while, but for operators (Operator-RW) and readonly-users we need html5 asap.

While CA migrated from Spectrum 7.x from Spectrograph to Oneclick, they used the same strategy. .. readonly-first, admins last.

 

I know that it is hard to replace the Topology-View via HTML5, but it is doable.

 

There are some HTML5-Libraries available - opensource or others to display and manage topologies.

 

Examples for inspirations for topologies:

telefonicaid/cne-tnetwork · GitHub

http://otm.github.io/networkmap.js/

https://github.com/otm/networkmap.js

https://gins.garr.it/Weathermap/mapgen_auto.php?type=user&id=g

http://hman-projects.de/mapael/jquery-mapael-master/world.html

 

.. but I think, the problem will be more to provide a good Alarm-List which is fast enaugh to display al alarms in an acceptable time and works as the old one in Oneclick.

 

Best Regards

Erich

02-14-2015 09:49 PM

Agreed. That would be a good start. I can't count the funny looks i've gotten when i tell people that the brand new tool we just purchased doesn't have a web component for users to use.

02-13-2015 02:42 PM

I'd prefer to see java wiped out completely in favor of a complete conversion over to HTML 5 or something similar, but this would indeed be a good start.

02-13-2015 05:24 AM

How about having a Java Applet in teh web page to show the OC topology?

Yes, there will be Java issues again, but would that not be a good starting point?

 

Thoughts?

 

Regards,

Kiran Diwakar

01-22-2015 05:15 PM

Yes, after the bugs and problems with the java at the Client-Side, HTML5 would be much better.

I had already started play around with the REST-API and was able to fetch the alarms, ... customers did the same. I am not alone with that try&error.

Next thing was to find out how the topology-views are created and stored.

... after some try&error-test, I came to the final that the Models and their X/Y-Positions are stored in the container-model which keeps them ... it is the attribute VIB_IIB_List , The Structure: - 4 Bytes header followed by 20 Bytes per Model. The 20 Bytes are: Model-Handle, ModelTypeHandle, X, Y-Position. Finally it looks more like a CSV-File rather than a normalized database. .. it took me some years to find the attribute. I allways thought that these informations are stored in the relation between Child-models and their Container-Models. .. I had worked to long with relational databases.

 

With that information, it will be possible to build a Topology-View without JAVA *-) .. or it will be possible to export the information to import into the next tool.

 

What are the others doing ?

09-24-2014 11:25 AM

Chris_Knowles, check out the webcast from earlier this summer. UIM should be that effort. However, i doubt ADA and APM will be part of it since CA doesn't see the connection.

09-24-2014 11:24 AM

Ha, I would like the poller's to talk to each other instead of having to rely on the MLS, this way we don't have to worry about having duplicate devices and the mapping functionality would work better instead of always having to have a poller that does nothing but create maps and you having to put those duplicate devices in as a proxy model....Frustrating.

09-24-2014 11:20 AM

The APM team moved most of the CA Introscope (Wily) java console functionality to a web based client last year with the 9.5 release of APM.  Perhaps the folks that helped make that happen could spend some time with the Spectrum team to get this going the same way??

 

Wouldn't it be nice if all the CA products that are supposed to play together would actually have a common interface?  (sorry, old soap box issue for me!!)

09-24-2014 11:09 AM

I once had a CA guy tell me that Spectrum is a product developed by consultants, sold by consultants, to be configured and supported by consultants.

09-24-2014 10:58 AM

This is a big deal for me as well. I can't keep sending out a new version of JAVA for every version of Spectrum released its just not practical. Right now this factor alone limits me from patching and upgrading so I'm always behind. There are so many users that have Java apps for this and that, any change in the version means possibly breaking someone else's tool. My only work around that I am seriously considering is to virtualize the app to make it client side agnostic but that is just more hoops to jump through as well as I need to account for the availability of Spectrum being accessible if a Citrix outage or DR type of an event were to happen. I have already heard 1000 reasons why you keep changing the version of Java on every release I get it... but its the one thing that really holds us back from getting the full use of what we are paying for..

09-18-2014 09:29 AM

Thanks for the much appreciated update. Having a web-based Spectrum would finally give us a reason to retire Solarwinds Orion.  Please give us that functionality.

09-18-2014 01:26 AM

Hello Team,

 

Absolutely! We have a lot of things that we have under consideration and research.

Spectrum 64 bit is scheduled for the next release of Spectrum and we are working with some of the largest customers we have to ensure we have a right start, through an alpha (typically we do beta, but given 64 bit is a pretty big overhaul of the product, we are starting first with an alpha and then a broader beta early next year).

 

We understand that the client requirements for some customers are something that make a web based UI a lot more appealing. Again, we are looking at options and leveraging some work that other CA teams are doing. We haven't reached a point where we can take a call based on the effort/cost. As you would imagine, things like 64 bit, Spectrum mobile, support for wireless Access Points and Hot Spots, Virtual Port Channel, Cisco VSS and over 350 device certifications planned in the coming few quarters are keeping us very busy!

 

Having said that, we really appreciate your constant inputs and I assure, we will ensure we give it an appropriate review and come back to you with an honest analysis of what and how much can be done.

 

Regards,

Kiran Diwakar

09-11-2014 07:13 AM

I agree. Spectrum needs to keep up with technology changes similar to the competition. Take SolarWinds products for example. They keep it simple.

Look at HP - OpenView NNMi which is 64-bit capable and Manage Engine - OpManager with there FLUIDIC UI which can load pages less than 100 ms.

09-05-2014 10:02 AM

On top of that I would like to see it be 64-bit and able to use multiple processes

08-31-2014 12:20 PM

Can't agree enough. HTML5, CSS3, and JS/jQuery are powerful enough to run loops around a java based client.