how test application messaging queue
Čo je to front správ?
Fronta správ (MQ) , nástroj na správu orientovaný na middleware, je IBM produkt od roku 1992. Je veľmi užitočné komunikovať správy (XML / textový súbor / HTML súbor atď.) v SOA (service Oriented Architecture) na viac ako 80 platformách.
Je spoľahlivý a poskytuje zabezpečené a zabezpečené komunikačné médium a vynikajúce riešenie správ Enterprise Architecture naprieč zeme.
Dnešný článok je o testovaní frontu správ, ktorý uľahčuje prepravu správ medzi dvoma aplikáciami / modulmi. To vám pomôže otestovať pripojenie medzi aplikáciami / modulmi počas prepravy správ.
Čo sa dozviete:
- Príklad systému správ v reálnom čase
- Aplikácia s MQ
- Technický príklad
- Funkčné testovanie s MQ
- MQ v SOA
- Problémy súvisiace s MQ počas testovania
- Záver
- Odporúčané čítanie
Príklad v reálnom čase Fronta správ systém
Vezmime ICICI banka ktorá obsahuje mnoho paralelne fungujúcich systémov na vytvorenie jednej kompletnej aplikácie. Predpokladajme, že ICICI banka ukazuje ročné ziskové rozpätie 100 miliónov dolárov za rok 2015.
Tento zisk by predstavoval súhrn všetkých systémov, ako sú sporiaci účet, účet na kreditnej karte, účet na pôžičku na bývanie atď.
Banka ICICI ako materský systém vyhľadáva komunikáciu z každého zo svojich samostatných systémov. Túto komunikáciu môže v prvom rade uskutočniť Fronta správ systém.
Materská banka ICICI môže poslať požiadavku, že potrebuje hrubý zisk z aplikácie Sporiaci účet. Aplikácia sporiaceho účtu potom tieto informácie vypočíta, uloží ich vo forme XML a umiestni ich do vzdialeného frontu.
Nadradený systém potom zavolá vzdialený front na získanie týchto informácií.
Aplikácia s MQ
Konfigurácia kľúča v SQM zakladá Správca frontu .
Ďalej je uvedených niekoľko dôležitých podrobností o správcovi front
- Vlastní / riadi úplné fungovanie Aplikácia WebSphere MQ .
- Nie je zodpovedný za prenos údajov.
- Obsahuje kanál a port na prenos údajov do konkrétneho cieľového frontu alebo na interné uloženie správy, kým si iná fronta správu nevyberie.
- Aplikácie môžu mať viac správcov / kanálov fronty na komunikáciu správ.
Technický príklad
Predpokladajme, že existujú aplikácie APPS, APPP, APPF, APPL, APPD . Všetci navzájom komunikujú správy. Niektoré z nich majú obojsmerné komunikačné štruktúry .
- APLIKÁCIE je predajná aplikácia so správcom front-APPSQM, channel-APPSCH, názvom frontu-MQS, portnum-11112
- APPP je aplikácia na spracovanie produktu s manažérom frontov-APPPQM, kanálom-APPPCH, názvom frontu-MQP, port-1111
- APPF je hotová, plne funkčná aplikácia s správcom front-APPFQM, kanálom-APPFCH, názvom frontu-Mqf, portnum-1112
- APPL je logistická aplikácia s manažérom frontov-APPLQM, channel-APPLCH, názvom frontu-MQD, portnum-1112
- APPD je doručovacia aplikácia s manažérom frontov-APPDQM, kanálom-APPDCH, názvom frontu-MQD, port-1112
Scenár 1 - APPS odosiela dáta do APPP
Každá z vyššie uvedených aplikácií bude mať dva konfiguračné súbory, konfiguráciu aplikácie a Fronta správ konfigurácia. Konfigurácia aplikácie obsahuje podrobnosti o postupoch a spracovaní údajov pre správu XML.
The SQM konfiguračný súbor bude mať SQM súvisiace podrobnosti ako správca front-APPSQM, kanál-APPSCH, názov frontu-MQS, portnum-1111.
( Poznámka: Pre zväčšenie kliknite na obrázok)
Raz APLIKÁCIE aplikácia spracuje údaje, vygeneruje správu XML a zaradí ich do poradia. APLIKÁCIE práca je hotová.
Je čas vybrať si správu z druhého frontu, dovtedy bude správca front uchovávať údaje.
Teraz si povedzme APPP aplikácia by mala vybrať správu XML z frontu MQS. The APPP Konfiguračný súbor MQ je nakonfigurovaný na načítanie správy XML z frontu MQS.
Fronta MQP načíta správu XML z frontu MQS a odošle ju do APPP žiadosť o ďalšie spracovanie.
Podobné procesy vykonáva každá aplikácia na získanie údajov z iných aplikácií.
Scenár 2 - APPP posiela dáta do APPS
Konfiguračné súbory budú tentokrát na oboch stranách odlišné. Konfiguračný súbor MQ na APPP bude mať rôzne informácie o fronte, ako napríklad Queue Manager-APPPQMR, channel-APPPCHR, názov frontu-MqpR, portnum-1111.
A APLIKÁCIE bude mať rôzne informácie o fronte, ako napríklad Queue manager-APPSQMR, channel-APPSCHR, názov frontu-MqsR, portnum-1111. Pamätajte, že číslo portu môže byť pre niekoľko aplikácií rovnaké, pretože môžu byť pripojené ako rovnocenné zariadenia v rovnakom systéme.
Preto všetky aplikácie budú musieť byť zodpovedajúcim spôsobom nakonfigurované na vzájomnú komunikáciu medzi správami.
Existuje možnosť, že môže dôjsť ku komunikácii medzi lokálnymi aplikáciami, ktoré sú v súčasnom systéme, so vzdialenou aplikáciou inde. Ako už bolo spomenuté vyššie, lokálne aj vzdialené aplikácie by mali mať na svojom serveri nastavené konfiguračné súbory umožňujúce komunikáciu.
Ako je spomenuté vyššie, lokálne aj vzdialené aplikácie by mali mať na svojom serveri nastavené konfiguračné súbory umožňujúce komunikáciu.
Funkčné testovanie s MQ
Testéri budú musieť potvrdiť nasledovné
- Konfigurácia aplikácie
- Konfigurácia frontu
- Formát správy
- Správnosť a úplnosť správy
- Prenos správ
- Zlyhania správ, keď k nim dôjde
MQ v SOA
SQM je spoľahlivá technika, ktorá sa dá použiť v SOA architektúru na komunikáciu správ medzi aplikáciami. Pretože komunikácia správ je kľúčovým konceptom pre spustenie systému ERP, SQM poskytuje správne riešenie.
Je to jednoduché a bezpečné. Na základe podobného prístupu, aký je uvedený v technickom príklade,
Na základe podobného prístupu, aký je uvedený v technickom príklade, Fronta správ je možné nastaviť na viac aplikácií na načítanie údajov z jednej alebo viacerých aplikácií.
Pohľadom na architektúru aplikácie môžu testéri získať viac informácií o komunikačnej konektivite správ medzi aplikáciami, toku správ E2E atď.
Tím MQ alebo tímy pre prostredie môžu v každom prípade poskytnúť ďalšie podrobnosti.
veci, ktoré môžete robiť v c ++
Simulátor MG (ako napr IBM WebSphere ), ktorý môže prenášať správy z prichádzajúceho frontu do výstupného frontu, je možné použiť na vypúšťanie správ, sledovať ich a kontrolovať príjem vo výstupnom fronte s variabilnými konfiguráciami.
Počas testovania aplikácií, ktoré komunikujú správy prostredníctvom Fronta správ , existuje veľa scenárov, pri ktorých môže zlyhať prenos správ z jednej aplikácie do druhej.
Niektoré z bežných problémov sú uvedené nižšie
- Problémy so vstupným formátom správ XML, ako je nesprávna hlavička, problém s metadátami, problém s formátom, problémy s údajmi atď.
- Nesprávna konfigurácia frontu, napríklad nesprávny názov frontu, názov správcu, kanál, port atď.
- Veľkosť správy môže byť viac, ako sa očakávalo, správa spadne do priečinka s chybami alebo mŕtvymi radami.
- Problém so serverom frontu, problém s pripojením, problém so vzdialeným frontom atď. Vedie k zlyhaniu komunikácie so správami.
Záver
Pri testovaní nasledujúcich aplikácií SOA , ako napr ERP systémy , MQ sú integrálnymi prvkami a ako testeri je dobré porozumieť základným podrobnostiam toho istého.
Dúfame, že sa tento článok podarilo predstaviť tento koncept a otvoril cestu ďalšiemu skúmaniu a ovládnutiu.
O autor: Toto je článok od Asisha K Mallika.
Zdieľajte svoje komentáre, otázky a vstupy nižšie.
Odporúčané čítanie
- Hĺbkové návody pre zatmenie pre začiatočníkov
- Výukový program AWS Elastic Beanstalk pre nasadenie webovej aplikácie .NET
- Výukový program pre migráciu SVN na IBM Rational Team Concert
- Výukový program pre nástroj na správu chýb IBM Rational Team Concert
- Tvorba jednostránkových aplikácií pomocou AngularJS (návod s príkladom)
- Prioritný front v STK
- Výukový program Java Reflection s príkladmi
- Ako simulovať a simulovať JMS IBM WebSphere MQ s Traffic Parrot (Hands on Review)