Posts Tagged ‘Service’

Netcool/Impact and ServiceNow!

Friday, December 6th, 2013

Have you ever tried to integrate Netcool/Impact and ServiceNow! ?

ServiceNow!… It’s an interesting piece of software I must admit and it’s in a public cloud, in Internet. You can create a lot of customizations and your own project and applications like CMDB, incident management, problem management, probably marketing people from SN! would tell you more benefits.

I’ve had a need to integrate my Impact 6.1.1 with SN! via SOAP recently and just wanted to share few general tips.

1. SN! WSDLs seem to be not correctly generated for Axis2 and must be manually adjusted before you approach compiling them in Netcool/Impact, I basically go and open my WSDL, I visit every complextType entry and remove the name parameter and value, so I leave <complextType> only. Only with this your WSDL will compile in nci_compilewsdl. Thank you Yasser from Impact dev team to pointing me to that one! 馃檪

2. SN! CA-signed certificate must be imported to your ImpactProfile WAS. It’s Entrust Inc. And here’s the full instruction for Impact:

3. You’ve got a basic HTTP authentication in SN! and probably won’t be allowed to switch it off, then compilation of WSDL is possible only locally with a downloaded WSDL file (both from CLI and GUI).

4. Policy generated by wizard is good and works well, usually a single parameter being selected helps it working better since the beginning (so you generate WSParams variable correctly).

The documentation of SN! in wiki is pretty well however not everything is documented and beware of your version of ServiceNow!

Everything else depends on your needs, if this is incident management integration (opening tickets) or CMDB (importing service trees to TBSM).

That would be it. I’ll share more after I finish my integration with TBSM.


Tickets please!

Tuesday, July 2nd, 2013

You must have come across the tickets system integration with BSMs. No, it’s not a blog entry about municipal transportation services here in Krak贸w (not too bad I must say, we still miss metro / subway and it’s as good as traffic with our roads allow to, so… 馃槈

BSM can open tickets, independently on critical events escalation or too big amount of critical events escalation. It can be based on, say, bad service component status which is based on mixture of badly looking KPIs, alarms or all together (even based on too many open tickets, ekhm). But how to design it smart?

I’ve been working on few integrations recently and there are few good answers to this question. The first one, obvious, almost boring and very evangelistic is: TALK TO YOUR CUSTOMER. How often have you heard of that advise btw? Man, probably too many times. But it’s true. Well, not just because it’s so smart, also because when it comes to lawyers, it’s always better to have a defense line in written in your SoW. Kidding 馃槈 Well, kind of at least.

So Talk To Your Customer rule still applies. The thing is we need to know scenarios when exactly tickets would open. And update. And close. Opening tickets for known issues based on event catalog seems obvious – alarm fields meet ticketing criteria, BSM sends signal to open a ticket in Trouble Ticket System (aka Incident management system aka Service Desk aka Service Request system, Man, looks like a lot of synonyms were created just to prove one names giver is more precise or smarter or knowledgable than others. I almost hear: “ohohoh, good Lord, it’s so obvious they’re not the same things, you ignorant!”). Back to track. So event manager instructs the TT system to open ticket, next enriches the ticket which originated the alarm with its ticket ID and acknowledges the alarm, so operators can see that alarm has been taken care of automatically based on existing knowledge base and event catalog and there’s been even an automated,聽 creative (let’s say) action taken – means escalation to ticket, and field support guys are already on their way to the failing device to fix it, replace it or report some unexpected issues like lost cat walking on chassis. After work is done they report the ticket solved, incident manager approves it and alarm can automatically clear.

That’s all truth if you don’t have:

  • single point of failure, so we assume there’s redundancy or high availability for function of the device so everybody will survive without that device availability for a while
  • service level agreement in place – I just thought up that point, well let’s assume you signed a service level for your device as a resource with the device vendor or service provider who installed that device for you and is still responsible for it by power of SLA. It helps with fixing the device part, vendor’s services start their troubleshoot job from this place.
  • anything to report to anyone so you don’t need a maintenance window to run at hoc the quickest you can in order to save your results in historical reports on availability of everything that was supported by the failing device. Simpler – you don’t have to take cover by announcing a maintenance window, so you basically don’t have to manage the maintenance windows at all. Unlikely.
  • business service management in place – so you basically have no idea about dependencies on that failing device of anything and you happilly go lucky about that.

BUT. If any of situations above concern you as not true, then design of the BSM and ticket system integration will look different.

You need to:

  • define precisely conditions to open, update and close tickets – frequency, conditions, user roles, interfaces etc.
  • define data sources for tickets – tickets may open not just based on alarms, also based on KPIs combination with alarms etc.
  • understand if any tickets can be neutralized by planned maintenance
  • if there is any logical elimination of opening automatic tickets for systems which depend on the original ticketing root cause (tell root cause from symptoms)
  • understand your knowledge base to open tickets automatically vs. manually. Some tickets openings can never be smartly automated.
  • use BSM to address tickets smartly, make it depended on service owner strategy or output mixture based on availability and KPIs
  • determine tickets priorities based on signed SLAs
  • determine all dependencies of any applications or systems on the failing device, so explore an option to open tickets automatically also for dependants

There’s proably more smart advises to share, but that’s what has come to my mind quickly tonight. I welcome any more comments or suggestions about this topic. And wish all good night.

Business Service Composer – pain in the… artifact?

Friday, March 22nd, 2013

I’ve been starting actively using Business Service Composer for creating my service trees in TBSM It’s really powerful tool, that helps you doing a lot of things with service structure, regardless component CDM classes (or any classes in any namespace, regardless their origin), however with one big glitch – it’s a huge step back in single administration console approach by deselecting TIP to be portal of choice in Tivoli and using Java GUI instead. There are two conveniences:

– If you really want to enjoy BSC GUI – don’t use it via ssh tunnel from within your Putty session to TBSM server (MS Windows users). Loosing focus on buttons or just selected menu items is so frequent that more times it doesn’t work and confuses than it works ok. It’s a nightmare, let’s put it straight. Just run it on your local workstation instead, it will save you a lot of nerves and time.

– But – once you run it on your desktop, you’ll have to come over the pain of updating project files via SCP (Windows users) there and back again in order to upload any single change to your static resources or policies.

It would probably be better if you run it all mounted locally from a remote site, where projects directory remains already in the right place for xmltoolkit script to pick it up and load it to artifacts without all that copy nightmare.

This is it. Powerful, conditionally usable, still some way from a nice tooling. And has nothing to do with TBSM Service Editor. Confusing? We have application descriptors and templates to model a dependency of CIs to applications first, then we have some functions of TADDM GUI, then we have BSC and at the end we have TBSM Service Editor. Confusing? It all works and has special use, but I’d have piece of a better advice for development. And I promise to share it.


TBSM in telco industry

Tuesday, April 12th, 2011

After months of break in posting on my blog, I’m coming back and publishing again. After spending a few months in one, bigger project for one of our bigger customers in Europe I’m full of different thoughts on TBSM and its technical use scenarios, as well as on business perspectives of getting this kind of tools to work. I will do my best to present all the interesting aspects and observations and share some of my experience.
First thing to mention is definitely form of my blog. Still the same, maybe will change the layout, but I’m definitely switching to English. Reasons can be justified by business, I believe that english publications remain valuable for polish engineers who may be looking for an interesting content in my blog, and who mostly speak english anyway, and remove the natural language barrier for audience from all over the world. I also believe in delivering more interesting content from now on and rely on your feedback more.
Like I mentioned, I’ve been participating in large TBSM project for telecommunications company in role of implementer and solution co-designer. It’s been very interesting time, lot of experience to gain, long hours and evenings spent over business services design, status and KPI rules, and dashboards. Product such as TBSM, which is highly customizable, and can basically be used in so many ways, may give you both lot of fun and trouble. Up to how open is your solution scope, TBSM design itself can take regular project time or way longer.
There are many things to say how to deal with such project requirements, how to address customer’s suggestions, how to translate use scenarios to TBSM service model, rules and dashboards. But I think it’s better to start from, say, “demythologization” of what TBSM can do and is for.
TBSM is not a network manager tool, or if you prefer – network topologies or hierarchies visualization tool. It’s rather obvious, but service models design may confuse you especially when you try to show dependency of some devices functions on other devices functions. Like you know, everything in TBSM is a service, or business service, even if representing a device, an application or a process. So presenting those objects in TBSM, named after their real, original name, like BSC or SGSN, and links connecting them in Service Viewer portlet, may confuse people less familiar with the tool and drive their minds to think that graphical link represents a physical link between devices, so has a critical meaning for signalling or data flow. Also naming services after devices doesn’t help here. Like I said, TBSM is not network manager or monitor, it just doesn’t have the right tools, like ping, telnet or cgi scripts, even though can present network objects with nice icons, KPI results and SLA violations. For network manager, you’re recommended to learn more about ITNM (IBM Tivoli Network Manager, former Micromuse Precision), if speaking about Tivoli. For open source, they’re writing interesting stuff on op5 in Linux magazine (at least recently in polish edition). For simple visualization of links between locations, I encourage to try Netcool Webtop Maps (new Webtop version was named WebGUI).
Second thing, TBSM can show many services in a tree or relationships view, but there’s a reasonable limit. They say 50’000-100’000 is fair limit nowadays. And 50 child services per parent. But watch out the product role again. It’s business services manager. Are you really running 50’000 business services in your company? So services that you make money on and their components? If yes, you must be IBM! 馃檪
Of course I’m kidding, you may run many services, much more than that and I don’t know how many services they could identify in IBM in WW total. It’s not the point. It’s rather a question: which services are important to you enough to spend weeks on analysis and workshops, identifying their dependencies, collecting technical details, establishing the missing and reconfiguring the existing monitoring and performing all tests? It still can be many, like hundreds top level services plus 10 levels of key components. But all the key components presence in TBSM service models should be justified and reasonable, and preferably: pre-documented, in order to deploy and implement a working solution on time. So TBSM shall be the last place where unverified and unconfirmed service topologies come in.
Last but not least, TBSM audience. I’ve done many projects after which TBSM box landed on shelf. So many customers order it, pay for it (maybe was volume price), are interested in it, after then just one enthusiast remain engaged and all the other personell switch back to old good monitoring tools they know from a decade. Or worse for both IBM and the customer: project slows down, become a critsit and even gets fixed, but bad impression remains. I’m that lucky that my recent project has been done by many enthusiastic people and also the customer, one among a few, has had a realistic vision of and need for TBSM use. It’s a pleasure to work with such mature customer, who is aware of TBSM place in their infrastructure and plans TBSM to be part of their information flow. Likely real life issues and obstacles, usually coming up during every implementation, are way easier to solve if there’s common understanding of what TBSM can and cannot do, and the only question remains open: when this all will be ready?
I hope to share some more interesting thoughts soon. I also encourage you to share your opinions on TBSM projects in different companies and industries, in general or in particular. Topic doesn’t really matter, can be about TBSM or Tivoli. Tivoli’s competition in monitoring or open source. Feel free to post your thoughts. I’m looking forward to hear from you about your bad experience with TBSM, Tivoli or IBM, as well as well done projects and what you’ve learned from them. Welcome and post you soon.

Energy Management

Sunday, September 13th, 2009

W poprzednim wpisie pisa艂em o tym, 偶e w TBSM 4.2.1 zosta艂 udost臋pniony pakiet integracyjny Energy Management Dashboards. Jest to pakiet zawieraj膮cy definicje modelu us艂ug, szablonu nawigatora oraz instrukcji dotycz膮cych 艂膮czenia TBSM z funkcjonalno艣ci膮 pakiet贸w ITM for Energy Management (ITMfEM) oraz dodatkiem do ITMfEM – Reporting & Optimization.

Czym jest Energy Management Dashboards w TBSM? Funkcjonalno艣膰 pakietu sprowadza si臋 do skonfigurowania strony TIP, kt贸ra gromadzi w spos贸b mash-up nast臋puj膮ce dane:
– wykres wydajno艣ci infrastruktury Data Center, mierzonej w %
– wykres obci膮偶enia system贸w ch艂odzenia, mierzonego w tonach
– wykres pojemno艣ci urz膮dze艅 podtrzymywania napi臋cia UPS, w zakresie do 80%, 80-90% i powy偶ej 90%, per urz膮dzenie
– portlet typu szablon nawigacyjny (tree template) dla modelu us艂ug kategorii urz膮dze艅 (np. Computing, Cooling, Power, Metering itp) do powi膮zania z urz膮dzeniami zg艂oszonymi przez xmltoolkit
– standardowy tr贸jzak艂adkowy portlet typu Szczeg贸艂y us艂ugi (Service details)

Aby tablica (dashboard) zadzia艂a艂a, nale偶y zasili膰 j膮 danymi. Podstawowe dane pomiarowe s膮 wyci膮gane z hurtowni danych TDW, kt贸ra w tym wypadku jest zasilana danymi zebranymi przez agent贸w ITM z pakietu Energy Management (kod ke9). Zdarzenia standardowo s膮 przekierowywane z sytuacji ITM przez sond臋 EIF do serwera ObjectServer w OMNIbusie. Model mo偶e by膰 zbudowany z modelu us艂ug wykrytego przez聽 TADDM lub z ksi膮偶ki IDML poprzez adapter DLA. Aby zadzia艂a艂y wykresy, nale偶y zainstalowa膰 pakiet ITMfEM – Reporting & Optimization, kt贸rego s膮 cz臋艣ci膮. Wraz z instalacj膮 pakietu ITMfEM-R&O dostaniemy te偶 nowe raporty BIRT w TCR.

Jaka jest warto艣膰 tablicy Energy Management? Ostatnio bardzo popularnym, ale i maj膮cym realne znaczenie ekonomiczne tematem, jest zarz膮dzanie zu偶yciem energii, kontrolowanie pracy urz膮dze艅 oraz poszukiwanie oszcz臋dno艣ci w obliczu rosn膮cych koszt贸w energii oraz zwi臋kszanej dba艂o艣ci o ochron臋 艣rodowiska naturalnego. Szablon nawigacyjny (tree template), pr贸cz modelu us艂ug i urz膮dze艅 zwi膮zanych z energi膮 zawiera dwie dodatkowe kolumny – zapotrzebowanie na energi臋 (Power demand [kW]) oraz bie偶膮ca temperatura (Temperature [C]). Mo偶emy wi臋c na bie偶膮co 艣ledzi膰 konsumpcj臋 mocy oraz wydzielane ciep艂o urz膮dze艅 pracuj膮cych w serwerowni. Przy odrobinie wyobra藕ni i dodatkowej pracy mo偶na r贸wnie偶 doda膰 przelicznik kW / PLN, a na podstawie zdarze艅 wygenerowanych przez TBSM przes艂a膰 sygna艂 do urz膮dze艅 r贸wnowa偶膮cych obci膮偶enie system贸w.

S艂owem – bardzo obiecuj膮cy pakiet. My艣l臋, 偶e mo偶emy spodziewa膰 si臋 kolejnych pomys艂贸w na tablice, z dziedziny zarz膮dzania aktywami (assets), bezpiecze艅stwem (security), jako艣ci膮 (service level) lub finans贸w (financial), by膰 mo偶e autorstwa IBM, a by膰 mo偶e partner贸w dzia艂aj膮cych w Tivoli OPAL.