how test application messaging queue
Vad är meddelandekön?
Meddelandekö (MQ) , ett meddelandorienterat verktyg för mellanprogram, är ett IBM produkt sedan 1992. Det är mycket bra att kommunicera meddelanden (XML / textfil / HTML-fil etc.) i SOA (serviceorienterad arkitektur) på över 80 plattformar.
Det är pålitligt och ger ett säkert, säkert kommunikationsmedium och en utmärkt meddelandelösning för Företagsarkitektur över hela jorden.
Dagens artikel handlar om att testa Messaging Queue som underlättar transport av meddelanden mellan två applikationer / moduler. Detta hjälper dig att testa anslutningen mellan applikationer / moduler under meddelandetransport.
Vad du kommer att lära dig:
- Realtidsexempel på meddelandekösystem
- Ansökan med MQ
- Tekniskt exempel
- Funktionell testning med MQ
- MQ i SOA
- MQ-relaterade problem under testningen
- Slutsats
- Rekommenderad läsning
Realtidsexempel på Meddelandekö systemet
Låt oss ta ICICI Bank det inkluderar många system som körs parallellt för att göra en komplett applikation. Antag att ICICI Bank visar en årlig vinstmarginal på 100 miljoner dollar för 2015.
Denna vinst skulle vara en sammanställning av alla system som sparkonto, kreditkortskonto, bostadskonto och så vidare.
ICICI-banken som modersystem söker kommunikation från vart och ett av dess enskilda system. Denna kommunikation kan främst genomföras av Meddelandekö systemet.
Förälder ICICI-banken kan skicka en begäran om att den behöver bruttovinsten i sparekontoapplikationen. Spara kontoapplikationen beräknar sedan denna information, lagrar den i form av XML och placerar den i fjärrkön.
Det överordnade systemet kommer då att ringa fjärrkön för att hämta denna information.
Ansökan med MQ
Nyckelkonfigurationen i SQM ställer in Köhanterare .
Några viktiga detaljer om köhanteraren nämns nedan
- Det äger / hanterar den fullständiga funktionen för WebSphere MQ-applikation .
- Det ansvarar inte för överföring av data.
- Innehåller en kanal och port för att överföra data till en viss målkö eller för att lagra meddelandet internt tills annan kö väljer meddelandet.
- Applikationer kan ha flera köhanterare / kanaler för att kommunicera meddelanden.
Tekniskt exempel
Låt oss anta att det finns applikationer APPS, APPP, APPF, APPL, APPD . Alla kommunicerar meddelanden med varandra. Några av dem har tvåvägs kommunikationsstrukturer .
- APPS är en försäljningsapplikation med köansvarig-APPSQM, kanal-APPSCH, könamn-MQS, portnum-11112
- APPP är en produktbehandlingsapplikation med köhanterare-APPPQM, kanal-APPPCH, könamn-MQP, portnum-1111
- APPF är en färdig, fullt fungerande applikation med köhanterare-APPFQM, kanal-APPFCH, könamn-Mqf, portnum-1112
- APPL är en logistikapplikation med köansvarig-APPLQM, kanal-APPLCH, könamn-MQD, portnum-1112
- APPD är en leveransapplikation med köhanterare-APPDQM, kanal-APPDCH, könamn-MQD, portnum-1112
Scenario 1 - APPS skickar data till APPP
Var och en av programmen ovan har två konfigurationsfiler, applikationskonfiguration och Meddelandekö konfiguration. Applikationskonfigurationen innehåller detaljer om procedurer och databehandling för XML-meddelandet.
De SQM konfigurationsfilen kommer att ha SQM relaterade detaljer som köhanterare-APPSQM, kanal-APPSCH, könamn-MQS, portnum-1111.
( Notera: Klicka på bilden för förstorad vy)
När APPS applikationen bearbetar data, genererar det XML-meddelandet och placerar det i kön. APPS jobbet är gjort.
Det är dags att välja meddelandet vid den andra kön tills dess att köhanteraren kommer att hålla data.
Låt oss nu säga APPP applikationen ska välja XML-meddelandet från MQS-kön. De APPP MQ-konfigurationsfil är konfigurerad för att hämta XML-meddelandet från MQS-kön.
MQP-kön hämtar XML-meddelandet från MQS-kön och skickar det till APPP ansökan om vidare behandling.
Liknande processer utförs av varje applikation för att erhålla data från andra applikationer.
Scenario 2 - APPP skickar data till APPS
Den här gången är konfigurationsfilerna olika på båda sidor. MQ-konfigurationsfilen på APPP kommer att ha olika köinformation som köhanterare-APPPQMR, kanal-APPPCHR, könamn-MqpR, portnum-1111.
Och den APPS kommer att ha olika köinformation som köhanterare-APPSQMR, kanal-APPSCHR, könamn-MqsR, portnum-1111. Kom ihåg att portnumret kan vara detsamma för få applikationer eftersom de kan anslutas som kamrater i samma system.
Därför, alla applikationer måste konfigureras i enlighet med detta för att kommunicera meddelanden med varandra.
Det finns en möjlighet att en kommunikation kan ske mellan lokala applikationer som finns i ett aktuellt system med en fjärrapplikation någon annanstans. Som nämnts ovan bör både lokala och fjärrprogram ha konfigurationsfiler att konfigurera på sin server för att möjliggöra kommunikation.
hur man skapar ett falskt e-postmeddelande
Som nämnts ovan, både lokala och fjärrprogram bör ha konfigurationsfiler att ställa in på sin server för att möjliggöra kommunikation.
Funktionell testning med MQ
Testare måste verifiera följande
- Programkonfiguration
- Kökonfiguration
- Meddelandeformat
- Meddelandets korrekthet och fullständighet
- Meddelandeöverföring
- Meddelandefel när de inträffar
MQ i SOA
SQM är en pålitlig teknik som kan användas i SOA arkitektur för att kommunicera meddelanden mellan applikationer. Eftersom meddelandekommunikation är ett nyckelbegrepp för att köra ett ERP-system, SQM ger rätt lösning för det.
Det är enkelt och säkert. Efter ett tillvägagångssätt som liknar det som visas i det tekniska exemplet,
Efter ett tillvägagångssätt som liknar det som visas i det tekniska exemplet, Meddelandekö kan ställas in i flera applikationer för att hämta data från en eller flera appar.
Genom att ta en titt på applikationsarkitekturen kan mer information erhållas av testare om meddelandekommunikationsanslutning mellan applikationer, E2E-meddelandeflöde etc.
I vilket fall som helst kan MQ-team eller miljölag ge ytterligare information.
MG-simulator (Till exempel IBM WebSphere ), som kan överföra meddelanden från inkommande kö till en utgående kö kan användas för att släppa meddelanden, övervaka dem och kontrollera kvittot i utgående kö med variabla konfigurationer.
Under testning av applikationer som kommunicerar meddelanden via Meddelandekö , det finns många scenarier där meddelanden inte kan överföras från en applikation till en annan.
Några av de vanligaste problemen nämns nedan
- Ange XML-meddelandeformatproblem som felaktig rubrik, metadataproblem, formatproblem, dataproblem etc.
- Felaktig kökonfiguration såsom fel könamn, chefsnamn, kanal, port etc.
- Meddelandestorleken kan vara mer än förväntat meddelandet hamnar i fel / död kömapp.
- Problem med köserver, anslutningsproblem, fjärrköproblem etc. leder till fel i meddelandekommunikationen.
Slutsats
När du testar appar som följer SOA , Till exempel ERP-system , MQ: er är integrerade element och som testare är det en bra idé att förstå grundläggande detaljer om detsamma.
Vi hoppas att den här artikeln har lyckats introducera konceptet och öppnat vägar för vidare utforskning och behärskning.
Om författare: Detta är en gästartikel av Asish K Mallik.
Dela dina kommentarer, frågor och inmatningar nedan.
Rekommenderad läsning
- Fördjupade förklaringar om förmörkelser för nybörjare
- AWS Elastic Beanstalk Tutorial för distribution av .NET-webbapplikation
- SVN till IBM Rational Team Concert Migration Tutorial
- IBM Rational Team Concert Defect Management Tool Tutorial
- Bygg en enskild sidapplikation med AngularJS (Handledning med exempel)
- Prioritetskö i STL
- Java Reflection Tutorial med exempel
- Hur man hånar och simulerar JMS IBM WebSphere MQ med Traffic Papegoja (Hands on Review)