Bilaga 4 Kundgränssnitt NeBI Light 2.0

Transkript

1 Bilaga 4 Kundgränssnitt NeBI Light 2.0 Innehåll Sida. BESKRIVNING 2.. Allmänt 2.2. Autentisering 2.3. Mottagningsadresser 2.4. Certifikat 3.5. Köhantering 3.6. Dialog 3 2. MEDDELANDESTRUKTUR AbilityRequest Ability Dialogen CancellationBySeller 2.4 Dialogen ErrorReportNotification 3 IN- RESPEKTIVE UTPARAMETRAR 2 4 IMPLEMENTERING OCH TEST 2 4. Implementering Testförfarande 2 Dokumentnummer T Rev Sid (2)

2 . Beskrivning.. Allmänt Kundgränssnitt NeBI Light 2.0 är ett gränssnitt som baseras på XML via JMS-kommunikation mellan Kunden och Network Sales. JMS-implementationen som används är Tibco EMS 4.2 och alla kundsystem är klienter som ansluter till TeliaSoneras server. För att kunna skapa uppkopplingen mot servern används ett JavaAPI som erhålles från Network Sales. Lösenord för att packa upp API-paketet är tpb I API-paketet finns en mapp ( tibco\ems\doc\html\index.htm ) med detaljerad dokumentation för JMSklienten. Kund TeliaSonera Network Sales Order/ Inköpssystem JMSklient Transaktioner B2B server Affärsstödsystem (BSS) & Produktionssystem (OSS).2. Autentisering Tillgång till Kundgränssnitt NeBI Light 2.0 förutsätter att konfiguration görs i brandväggar och system så att endast anrop från angivna IP-adresser släpps igenom. Inloggning görs med Användarnamn och Lösenord. All kommunikation mellan klient och server är krypterad. För autentisering erfordras certifikat, se punkt Mottagningsadresser.3.. Kundens mottagningsadresser Kunden skall meddela sin IP-adress för mottagning av meddelanden. Flera adresser (för test, produktion etc) kan förekomma. Aktuella adresser meddelas till Network Sales på särskild blankett Network Sales mottagningsadresser Både testsystem och produktionssystem är dubblerade. Testsystem IP-address tssipltst.ext.telia.se = tssipl2tst.ext.telia.se = Port ssl: 73 URL: ssl:// tssipltst.ext.telia.se:73, ssl:// tssipl2tst.ext.telia.se:73 Dokumentnummer T Rev Sid 2 (2)

3 Produktionssystem IP-adresser tssipl.ext.telia.se = tssipl2.ext.telia.se = Protocol: JMS Port ssl :74 URL: ssl:// tssipl.ext.telia.se:74, ssl:// tssipl.ext.telia.se:74.4. Certifikat Respektive parts certifikat (inkl fullständig CA-kedja eller ned till en av motparten känd CA) för SSL skall utbytas. Om Kunden saknar certifikat kan det enkelt anskaffas från någon leverantör..5. Köhantering.5.. Kö för meddelanden Kundens meddelanden sänds till kö TeliaSoneraIn.5.2. Kö för mottagning Kunden tilldelas en () kundspecifik kö för testmiljön och en () kundspecifik kö för produktionsmiljön som namnsätts av Network Sales enligt principen: Testmiljö testacc_q.system.kundnamn.external.tradingpartnerout Produktionsmiljö prod_q.system.kundnamn.external.tradingpartnerout Vid byte av miljöer i kundänden kan temporärt dubbla köer erbjudas under en övergångsperiod..6. Dialog Den generella dialogen som används är: Request Ability. Buyer Request Ability dialog Request Ability dialog AR Ability Request A Ability Supplier Denna dialog är en förenklad version av Order-dialogen. Syftet med denna dialoggrupp är att möjliggöra för Kunden att fråga om Network Sales kan leverera önskad produkt i enlighet med de villkor som specificeras i dokumentet [AbilityRequest]. Network Sales svarar genom att meddela om leveransen är möjlig, eller ej, genom att skicka dokumentet [Ability] Dokumentnummer T Rev Sid 3 (2)

4 2. Meddelandestruktur Strukturen på meddelanden beskrivs I NeBI-specifikationen. Nedan följer ett utdrag som behandlar AbilityRequest, och Ability. Generic Structure XSD describing PU -specific part NeBiEnvelope Business document PUC-specific part Included in business documentt XSD describing the generic business Document, eg Order, Cancellation etc XSD describing the NeBiEnvelope generic document NeBiEnvelope Dokumentnummer T Rev Sid 4 (2)

5 The business document NeBiEnvelope is the envelope for all NeBiEnvelope business documents, eg. Order and AbilityRequest etc. The business documents is placed in the Body element Header Document, dialog and routing information. Body Information associated with the specific business document. Trace Trace log for the document 0- Header party party Dokumentnummer T Rev Sid 5 (2)

6 Header To Identification of the reciever for this document From Identification of the sender of this document Dialog The formal name on this dialog, collaboration. This element is used to specify the service that receives and processes the message at the receiver side. The value of the Service element MAY be the name of the specific service in a business process, defined in advance. The content of the Service element MUST be a URI conforming to [RFC2396], e.g. nebi.biz:bc:order_.0 DialogId A unique id of the dialog. This value is decided in the first document of the dialog, following businessdocuments in the same dialog holds on to this value. The value is unique, e.g. Consecutive number@domain This element is used to specify the group of messages for which message ordering is guaranteed. This element is REQUIRED. This element MUST have a globally unique identifier as its value. The format of this identification is REQUIRED to be conform to MessageId, as defined in [RFC2822]. MessageType MessageId The formal name on this business document], e.g. BD:Order_L_.0. The MessageId element is a REQUIRED element. This element MUST have a globally unique identifier as its value. The format of this identification is REQUIRED to conform to MessageId, as defined in [RFC2822], e.g @teliasonera.com Refrerence Referencing a DialogId, OrderId or a MessageId. This element must be used to supply thecustomerid. -* SequenceId The sequence number of the businessdocument in the dialog. The SequenceNumber element is a REQUIRED element. This element is used for the message order within the group of messages categorized by the same DialogId. In other words, the sequence of numbered messages that the receiver node presents to the application MUST be in the same order as the sequence of numbered messages that the sender application has produced, within the group o f messages having the same DialogId value. Dokumentnummer T Rev Sid 6 (2)

7 Party Party OrganisationId Identifies a business party playing a role defined by the context of the business document. Note that both id and name is declared optional. If buyer and supplier have established a common and shared identity for the party (which is the case when supplier and buyer identify each other) the id must be present. Otherwise the name must be present. The party s identity. The supplier decides upon identities (or value domain or convention) and notifies the buyer about these outside of NeBI light before the business dialog is initiated. The value of this element MAY be a URI [RFC2396]. DestinationType The type of destination, eg. an Order queue. Destination The destination to an Order Manager or Business Systems. 2.. AbilityRequest Generic Part AbilityRequest Ability is used to represent a delivery inquiry. BusinessDocumentVersi on 5 ProductLine A number of LineSpecifications that describe the product use case to which inquiry refers and the conditions for each line. -* LineSpecification Linespecification Number ProductUseCase Details Identifies the line within a list of lines. The first line in an order or quotation has the number. The value of the line number is then incremented by for each new line. Deletion of a line may result in a gap in the numbering sequence. Any gap that arises may not be reused. Describes the product use case (PUC) that is referred to and any PUC-specific characteristic values that apply for Dokumentnummer T Rev Sid 7 (2)

8 this order or quotation. Must always be stated. Product Specific Part ProductUseCaseDetai ls Id Name Uniquely identifies one of the supplier s product use cases (PUC). Descriptive name of the PUC. Does not have to be stated. Should be seen as an alternative key value for id. 0- The Wildcard-part of the message is exchanged for the Product specific part called pucnfinput: Example of pucnfinput. Content in PUC Depending on the value of attribute Id there are different possibilities for input: Id Values present in tag 03 <tfnnr> 5 För Telefonnummersök Express <tfnnr> 5 För Adressök <adress> Dokumentnummer T Rev Sid 8 (2)

9 2.2 Ability Generic Part Ability Status ProductLine Ability is used to represent a response to a delivery inquiry. Denotes if supplier is able to deliver acording to the AbilityRequest. Optional attribute that is typically used to explain the conditions when abilitystatus = no. A number of LineSpecifications that describe the product use case to which inquiry refers and the conditions for each line. 0-* ProductLine Status Reason AbilityLine is a kind of LineSpecification,. Denotes if supplier is able to deliver acording to the AbilityRequest. A list of reason why abilitystatus is assigned no. Is represented as a ReasonType which makes it possible to refere to an specification of reason codes. 0-* Product Specific Part Dokumentnummer T Rev Sid 9 (2)

10 ProductUseCaseDetails Id Name Uniquely identifies one of the supplier s product use cases (PUC). Descriptive name of the PUC. Does not have to be stated. Should be seen as an alternative key value for id. 0- The Wildcard-part of the message is exchanged for the Product specific part called pucnfoutput: Example of pucnfoutput. Content in PUC Depending on the value of attribute Id there are different possibilities for output: Id Values present in tag 03 <PucNFInput> <abgtypflagga> <speckrav> <rvidd> <pdskbnow> <pdskblater> <pdeskbnow> <pdeskblater> <felkod> 5 <PucNFInput> Telefonnummersök <felkod> Express och <felmeddelande> Adressök <Stnlaengdlista> 5 Adressök <PucNFInput> <felkod> <felmeddelande> <adresslist> Dokumentnummer T Rev Sid 0 (2)

11 2.3 Dialogen CancellationBySeller B U Y E R Cancellation Request dialog Ability dialog CBS Cancellation S U P P L I E R Syftet med denna dialog är densamma som för dialogen ErrorReportDokumentation. Att båda förekommer beror på att det är olika system som genererar de båda typerna av meddelanden: Felaktigt användarnamn/lösenord Felaktiga parametrar i From/To-fälten Felaktig XML Systemfel I dokumentet som skickas ingår En referens till ett visst meddelande i elementet <Reference> En Felkod i Elementet <Reason><StatusCode> En Felbeskrivning i elementet <Reason><Description> 2.4 Dialogen ErrorReportNotification B U Y E R ErrorReportNotification Request Ability dialog dialog ERN ErrorReportNotification S U P P L I E R Syftet med detta meddelande är att skicka information om grundläggande fel i dialogen mellan Network Sales och Kunden. Felen som rapporteras med detta meddelande är av ickeproduktberoende karaktär såsom: Felaktigt användarnamn/lösenord Felaktiga parametrar i From/To-fälten Felaktig XML Felaktig referns till produkt I dokumentet som skickas ingår En referens till ett visst meddelande i elementet <Reference> En Felkod i Elementet <Reason><StatusCode> Dokumentnummer T Rev Sid (2)

12 En Felbeskrivning i elementet <Reason><Description> 3 In- respektive utparametrar Tabeller med in- och utparametrar och koder för att simulera olika typer av felaktiga transaktioner erhålls av Network Sales. 4 Implementering och test Uppgifter på vissa tekniska parametrar och data samt namn på ansvariga kontaktpersoner fordras för att implementering och test skall kunna genomföras. Uppgifterna lämnas på särskild blankett. Lämnade uppgifter kommer även efter testen att användas i produktionen. Efter cirka 0 dagar returneras blanketten till Kunden med uppgifter om könamn, användarnamn mm. Lösenord skickas som SMS till Kundens kontaktperson för test och tekniska frågor. Kunden får Tibco-klienten mailad till angiven mailadress. 4. Implementering Implementering sker genom att Kunden anpassar sitt affärssystem utifrån av Network Sales erhållen teknisk information, Övrig erforderlig information framgår av information om användning av JMSklienten. 4.2 Testförfarande 4.2. Allmänt Planering och genomförandet av testen sker i samarbete mellan parterna och dokumenteras i ett testprotokoll. När testen är avslutad undertecknas testprotokollet av bägge parter. Efter godkänd test beslutar parterna gemensamt om datum för produktionssättning. I API-paketet finns exempelfiler för Skicka meddelande och ta emot meddelande Obs! Det är inte säkert att testsystemet ger samma svar som produktionssystemet. Detta pga att testsystemet använder en databas som inte uppdateras lika ofta som databasen för produktionssystemet Genomförande Testen genomförs genom att: Kunden skickar normala förfrågningar och verifierar att svar på efterfrågade data erhålls från Network Sales, simulera olika typer av felaktiga transaktioner för att testa att gränssnittet genererar de svarskoder som erhålls av Network Sales Loopbacktest En så kallad Loopbacktest kan göras genom att sätta <To> lika med <From> i ett meddelande som skickas. Denna åtgärd gör att ett meddelande returneras från Network Sales utan att det analyseras. I de fall testerna avser produkt där förfrågan debiteras, debiteras Kunden även för testförfrågningarna. Dokumentnummer T Rev Sid 2 (2)