Ĉu vi konsideras translokiĝi al IBM Cognos Analytics en la Nubo, ĉu vi volas uzi JDBC-pelilojn anstataŭ denaska datumbaza kliento, aŭ nur pli grandan videblecon pri prezentaj rilataj trajtoj de demandoj, adopti Dinamikan Demandan Modon estas bonega ideo.
Kiam Performance Food Group, unu el la plej fidindaj gvidantoj en la manĝaĵa industrio lastatempe ĝisdatigita de Cognos 10.2.1 ĝis 11.0.12 kiel parto de ilia kontinua pliboniga procezo, ili decidis, ke ili ĝisdatigos ankaŭ siajn pakojn de CQM al DQM. Sumit Kumar, la IT-administranto de PFG respondeca pri kontrolado de raportado, analizo kaj konsultado, respondecis pri ilia paka migrado kaj taskis venki iujn ajn defiojn, kiujn ili povas renkonti dum ĉi tiu procezo.
Avantaĝoj Konverti De CQM Al DQM
La kialoj de Performance Food Group por migri estis multaj. Unu el la ĉefaj avantaĝoj de transformado por Sumit kaj PFG entute estis la kapablo uzi raportojn, kiuj enhavas datumojn de multaj pakoj ene de tiu sama raporto. Dinamika Demanda Reĝimo permesus al Sumit uzi raportojn, kiuj enhavis datumojn de pluraj temoj kiel vendoj, aĉetoj kaj inventaro, kvankam ili situas en tri tute malsamaj pakoj. Kongrua Demanda Reĝimo ne havas ĉi tiun kapablon, do la elekto estis evidenta.
Transformi de Kongrua Demanda Reĝimo al Dinamika Demanda Reĝimo ankaŭ havigus al ili la kapablon tre redukti raportan ekzekutan tempon per utiligado de la demandekzekuto pri 64-bita arkitekturo. Migrante, Sumit sciis, ke ili ne nur metas la infrastrukturon por plifaciligi estontajn ĝisdatigojn, sed ankaŭ donas al Performance Food Group la kapablon iniciati prognozajn analizojn en sia aŭtomatigo.
La avantaĝoj de konvertiĝo estis evidentaj, sed kiaj defioj antaŭis?
Post elektado de 13 Cognos-pakaĵoj por transformi, Sumit renkontis siajn unuajn obstaklojn dum la projektoplanado kaj ekzekutfazo.
Projektaj Planoj kaj Ekzekutaj Defioj
La unua roadbloko alfrontita de Sumit elektis inter Akvofalo aŭ Agile Delivery. Sumit elektis ĉi-lastan por sia CQM al DQM-konvertiĝo ĉar ĝi permesis al li deploji ĉiun pakaĵon sendepende. Pakaĵoj estis deplojitaj kiam ĉiuj gravaj raportoj sukcese funkciis kaj se iuj malaltprioritaj raportoj havis erarojn, ili deplojis la pakaĵon ĉiuokaze kaj riparis la raportojn poste. Ĉi tio permesis al ili liveri komercan valoron antaŭen sen perdi tempon, sed por ludi ĝin sekure ili konservis monatan bufron, se ili bezonus plian helpon de la IBM-produkta subtena teamo.
Nun kiam Sumit kaj Performance Food Group superis la projektan planon kaj ekzekutfazon, estis tempo por ili pritrakti la sekvan numeron: teknikaj kaj infrastrukturaj defioj pro la konduto de la pakaĵoj en Dinamika Demanda Reĝimo.
“Laŭ Sumit, transformi de CQM al DQM estis tempo kaj peno tre bone elspezita. Post la konvertiĝo, raporta ekzekutotempo reduktiĝis averaĝe je 60%! "
Teknikaj kaj Infrastrukturaj Defioj
Dinamika Demanda Reĝimo plenumas plej bonajn praktikojn, kiuj estis laŭvolaj en Kongrua Demanda Reĝimo. Ekzemplo de tio estus la uzo de streketoj kaj asteriskoj kun antaŭa oblikvo kiel komentita linio, ekzemple, '-' vs '/ *'. CQM akceptas ĉiujn ĉi tiujn dum DQM foje akceptas ĝin kaj foje ne, depende de lokado. Ĉi tiuj ŝajne malgrandaj problemoj povas kaŭzi sporadajn erarojn aŭ eĉ tutajn raportojn malsukcesi. Oni ankaŭ scias, ke komentoj pri altnivelaj filtriloj, SQL-pridemando kaj kutimaj kalkuloj kaŭzas erarojn. A Komparu SQL-demandon ilo estis konsiderita formati lokigon kaj redukti la aperon de eraroj de tiu areo sed la esploro iris plu por vidi ĉiujn erarajn okazojn. Inkludo de sumfunkcio en la datuma modelo aŭ paka difino ankaŭ kreis erarojn, sed ĉi tion eblas ripari anstataŭigante ĝin per totala funkcio anstataŭe, aŭ Sum () vs Total ().
Dinamika Demanda Reĝimo ankaŭ faras iujn supozojn, ke ne kongrua Demanda Reĝimo, kaŭzante diferencajn raportojn. Rilatado de raportoj en CQM kontraŭ DQM povas doni al vi malsamajn rezultojn nur surbaze de kiel ili interpretas la funkcion. Ekzemple, la Sumo (Sumo (Vendoj)) en CQM donos al vi rezulton, kiu ekvivalentas al totalaj vendoj kaj ignoras la duoblan sumon, dum en DQM ĝi ne ignoras la duoblan sumon, donante al vi alian raportan rezulton. Simile, la maniero kiel agregaj opcioj estas efektivigitaj en CQM vs DQM ankaŭ varias. La filtriloj en Kalkulitaj / Entutaj kolumnoj povas konduki al malsamaj rezultoj depende de entuta posedaĵa elekto, kiel "Antaŭ Agregado" aŭ "Post Agregado".
Aliaj Defioj
Dinamika Demanda Reĝimo povas apliki malsaman ordon de operacioj, kiuj povas kaŭzi ŝanĝojn en la raporta eligo.
- Raportnivela difino de kardinaleco kaŭzas ŝanĝojn en la raporta eligo.
- Raportvalidigo povas ankoraŭ montri kritikajn erarojn eĉ post kiam la avertaj mesaĝoj estas solvitaj. Ĉiuj avertaj mesaĝoj devas esti riparitaj antaŭ ol la raportokompililo povas montri al vi la realan eraron. Se raporto ne funkcias kaj nur montras avertan mesaĝon, vi devas unue ripari la avertan mesaĝon antaŭ ol la raporto malkaŝos la kritikan eraron kaj permesos ripari ĝin.
- Redakti raportojn kun grandegaj kvantoj da datumoj eble malsukcesos kun problemoj pri "Ĝava memoro" sed povas esti riparitaj malŝaltante la lokan kaŝmemoran posedaĵon en la raportaj propraĵoj por tiuj raportoj, kaj ankaŭ povas esti helpata pliigante la agorditan memoron por la konserva servo.
- Agordo de JVM devas esti agordita laŭ plej bonaj praktikoj por eviti estontajn problemojn.
Konklude
Laŭ Sumit, la migra procezo estis tempo kaj penado tre bone elspezitaj. Post la konvertiĝo, raporta ekzekuta tempo reduktiĝis averaĝe je 60%! Li sendube rekomendas konverti pakojn de CQM al DQM kaj vian ĉirkaŭaĵon de 32-bita al 64-bita.
Ĉu vi konsideras transformi de Kongrua Demanda Reĝimo al Dinamika Demanda Reĝimo aŭ ĵus konvertiĝi? Ni tre ŝatus, ke vi dividu vian sperton kun ni aŭ iujn ajn konsilojn kaj lertaĵojn, kiujn vi eble havas!
Ĉu vi volas lerni pli? Ni gastigis webinar kie ni diskutis la defiojn alfrontitajn de Performance Group dum ilia migrado al Dinamika Demanda Reĝimo. Respondu la retejon klakante ĉi tie.
