search

nav-gov-hu / Online-Invoice

Public repository of the Online Invoice System
Other
138 stars 52 forks source link

[Q&A] queryInvoiceDigest üres válasz #300

Closed csandazoltan closed 4 years ago

csandazoltan commented 4 years ago

HTTP 200-as válasz queryInvoiceDigest esetén teljesen üres. Szeretnék adatot lekérni queryInvoiceDigest api műveleten keresztül. XSD megfeleltetés szerint a kérés helyes, XML beküldésére 200-as válasz érkezik, de a válasz üres. Nincs hibaüzenet semmilyen válasz. Leírás szerint kapnom kellene xml választ, ha nincs tálalat az idő paramétereknek megfelelően ("availablePage" = 0)

Ma hajnal 3kor még volt válasz de most üres. Érdekesség, hogy van olyan bejelentkezésünk ami viszont ad választ. Tehát egyik felhasználónál működik az API a másiknál nem.

NTCA-developer commented 4 years ago

Szia @csandazoltan

Kellenének legalább az üzleti keresőparaméterek, hogy tudjunk valami elméletet felállítani.

era910413 commented 4 years ago

Sziasztok! Ugyanez van nálunk is, sőt a QueryTransactionStatusRequest esetében is ez van néha, melyet a 283-ban jelentettem. Azóta ezt lezártátok azzal h írjak a HD-nem, amit meg is tettem de még nem kaptam választ.

NTCA-developer commented 4 years ago

@era910413 de itt még nem tudni, hogy melyik környezetről van szó és a request bonyolultsága miatt lehet hogy van direkt logikai magyarázat is arra amit látunk. Egy transactionId lekérdezéshez meg nem nagyon van mit hozzátenni logikailag.

csandazoltan commented 4 years ago

Ami működik:

tax_number: 14929560 [invoiceIssueDate] dateFrom: 2020-07-01 dateTo: 2020-07-06 invoicedirection OUTBOUND és INBOUND

Ez helyesen 2 db számlát ad OUTBOUND módban és 10 számlát INBOUND módban

Ami nem jó és az üres válasz nagyságrendekkel lassabban érkezik:

tax_number: 25358805 [invoiceIssueDate] dateFrom: 2020-07-01 dateTo: 2020-07-06 invoicedirection OUTBOUND és INBOUND

Ennek a válasza üres, még üres eredmény xml válasz sincs

era910413 commented 4 years ago

Annyit hozzátennék, hogy az éles rendszerbe a 2018-as indulás óta több mint 170ezer számlát küldtünk be, mégis a 06.30-án történt leállás óta találkozunk ilyen problémával. A QueryTransactionStatusRequest azóta 156 db számlára nem ad nekünk választ, a weben mégis lekérdezettnek látszik. A mi hálózatért felelős kollégáink megnézték a logokat, beállításokat és nincs arra utaló jel, hogy a csomagok nálunk vesznének el. Ezért is vártam volna valamiféle segítséget, viszont hátha a HD majd megoldja..

A queryInvoiceDigest esetében nálunk szintén az éles rendszerben van csak gond.

Viszont bocsi a beleszólásért, most már csak megfigyelek, hátha a Zoltán által leírt példák alapján történik valami előrelépés.

NTCA-developer commented 4 years ago

Na várjunk. Szóval azt mondod, hogy a 25358805 adószámra történő lekérdezés nem ad vissza response bodyt csak egy natúr HTTP 200-at? Semmi válasz XML?

csandazoltan commented 4 years ago

Igen! curl_getinfo eredménye: 14929560: image

25358805 image

NTCA-developer commented 4 years ago

Akkor jönnek a kérdéseim.

@csandazoltan

@era910413

era910413 commented 4 years ago

Igen, pontosan ez történik.

NTCA-developer commented 4 years ago

@era910413

Akkor utólagosan is bocsánatot kérek, mindkettőtöknél félreértettem az üres válasz fogalmát. Nekem az üres válasz az a response XML, ami nem tartalmazza valamelyik üzleti csomópontot. Azért "pattintottam le" a HD-nek mert az általam gondolt eset eléggé gyakori és boldogulnak vele. De akkor ebbe is besegítek. Mi lett a bejelentés száma, elküldenéd?

csandazoltan commented 4 years ago

Nincs a curl-nek kifejezetten header paraméterben megadva, hogy Keep-Alive Kipróbáltam, hogy a CURLOPT_HTTPHEADER-be, beleraktam, hogy 'Connection: Keep-Alive', 'Keep-Alive: 300'

Nem hozott különbséget.

Nem tudom mi az a "HD", TransactionID-m nincs mert nincs válasz, csak RequestID

csandazoltan commented 4 years ago

Üres, üres :) a http response hossza 0

NTCA-developer commented 4 years ago

Bocs, a HD a Helpdesk lenne. :) Itt tudsz nekik írni: https://nav.gov.hu/nav/e-ugyfsz/levelkuldes

csandazoltan commented 4 years ago

De akkor most még maradunk itt, mert nem rossz response xml van, hanem nincs response xml? :)

era910413 commented 4 years ago

Lehet én fogalmaztam félreérthetően.. Szóval köszi hogy foglalkozol vele. Iktatószám: e-500910

NTCA-developer commented 4 years ago

@csandazoltan Igen, maradunk itt (is) és egyelőre hagyjuk nyitva ezt a Github ticketet. Még írd be az iktatószámát annak a hibajegynek amit beküldtél a HD-nak légy szíves. Utána megbeszélem a kollégákkal, hogyan és mi módon válaszolunk.

csandazoltan commented 4 years ago

Nem küldtem még Helpdesknek levelet, mert mint írtam nincs TransactionID, csak RequestID-m Az is jó?

csandazoltan commented 4 years ago

Elküldtem RequestID-val. Iktatószám e-501224

szecsenyizoltan commented 4 years ago

Az említett probléma Ubuntu 18.04 (LAMP) alatt nálam is jelentkezett (kb 2020.06.25-től), de Ubuntu 20.04 alatt nem. Nem találtam meg a hibát, de dist-upgrade megoldotta.

csandazoltan commented 4 years ago

@szecsenyizoltan És ugyanezt produkálta, hogy egyik felhasználó ment a másik 2 meg nem, 0 hosszú válasz érkezett? Mondjuk az is érdekes, hogy ugyanaz a szerver ugyanazon a napon működött is, meg nem is.

Valóban 18.04.4 Ubuntu van a szerveren. PHP 7.4.7

@era910413 Nálatok milyen szerveren fut a lekérés?

era910413 commented 4 years ago

Nálunk saját fejlesztésű Debian van, a gazdája állítja hogy azzal nem lehet gond :)

szecsenyizoltan commented 4 years ago

És ugyanezt produkálta, hogy egyik felhasználó ment a másik 2 meg nem, 0 hosszú válasz érkezett? Mondjuk az is érdekes, hogy ugyanaz a szerver ugyanazon a napon működött is, meg nem is. Valóban 18.04.4 Ubuntu van a szerveren. PHP 7.4.7 @csandazoltan

18.04.4 alatt nekem ez volt a hibaüzenet: Excess found in a non pipelined read: excess = 11240 url = /invoiceService/v2/queryInvoiceData (zero-length body)

Nem minden számlánál, de amelyiknél igen, ott mindig. Ugyanazt a számlát lekérdezve 20.04 alól nem volt ilyen gondom. Felteszem php/curl körül valami eltört egy frissítéssel ami ezt okozhatta. Mind a két LTS-n a szállított PHP-t használtam. Mivel a dist-upgrade benne volt a tervben így azzal kezdtem és szerencsére megoldotta a hibát, így a bugvadászat elmaradt.

csandazoltan commented 4 years ago

@szecsenyizoltan Köszönöm a választ! Ezt a php error logban volt, apache log?

Viszont amit írsz at a queryInvoiceData. Ott még nem tartok :) Én a queryInvoiceDigest-nél akadok el. De megnézném a logot

szecsenyizoltan commented 4 years ago

@csandazoltan Egyikben sem. Magában a válaszban volt ez az üzenet.

Szerintem a probléma ugyanaz és service-től független. Valamit rosszul küld el (zero-length body).

era910413 commented 4 years ago

Nálunk is ez van: Excess found in a non pipelined read: excess = 5595 url = /invoiceService/v2/queryTransactionStatus (zero-length body)

era910413 commented 4 years ago

Nálunk a curl-nak ez a verziója van: curl 7.26.0 (x86_64-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1t zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

Úgy látom, hogy a legfrissebb stabil kiadás a 7.71.1.. lehet picit le vagyunk maradva :D Nálatok milyen van?

szecsenyizoltan commented 4 years ago

@era910413 curl -V curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3 Release-Date: 2020-01-08

De ezzel már nincs gond.

18.04.4: https://packages.ubuntu.com/search?keywords=curl&searchon=names&suite=bionic&section=all

csandazoltan commented 4 years ago

Nálunk 7.58 a curl

Még mindig nem találom, az excess hibát, próbálok minden header, meg body adatot kinyerni a curl kérésből, de csak ennyit látok:

HTTP/1.1 100 Continue Content-Length: 0

HTTP/1.1 200 OK Connection: close Content-Type: application/xml;charset=UTF-8 Date: Tue, 07 Jul 2020 06:48:27 GMT X-Via: ppsaicxmlapi2.eszamla.local X-Server: backend_invoiceService-v2-queryInvoiceDigest/XML_kpx_B1 Strict-Transport-Security: max-age=31536000; includeSubDomains

era910413 commented 4 years ago

Mi ezeket raktuk bele: curl -S -v Így olyan outputot ad amiből látszik a hiba.

szecsenyizoltan commented 4 years ago

@csandazoltan

Itt egy példa arról hol kellene lennie:

> POST /getUserData_client HTTP/1.1
> User-Agent: curl/7.37.0
> Host: ec2-50-112-34-244.us-west-2.compute.amazonaws.com:8080
> Accept: */*
> Content-Length: 42
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 42 out of 42 bytes
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< X-Gearman-Job-Handle: H:ip-10-249-4-167:43
< X-Gearman-Command: GEARMAN_COMMAND_WORK_COMPLETE
< Content-Length: 0
< Server: Gearman/1.0.6
<
* Excess found in a non pipelined read: excess = 1133 url = /getUserData_client (zero-length body)
* Closing connection 0
csandazoltan commented 4 years ago

Mi meg php függvénytárat használjuk, nem CLI parancsokat futtatunk.

curl_setopt($ch, CURLOPT_VERBOSE, true); a curl_error() pedig üres

szecsenyizoltan commented 4 years ago

@csandazoltan

Én is azt használom.

   public function sendNAV() {
        $url = ("https://".$this->navConfig->getApiUrl()."/invoiceService/v2/".$this->service);
        $ch = curl_init($url);
        curl_setopt($ch, CURLOPT_VERBOSE, 1);
        curl_setopt($ch, CURLOPT_HEADER, 1);
        curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
        curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
        curl_setopt($ch, CURLOPT_URL, $url );
        curl_setopt($ch, CURLOPT_POST, true );
        curl_setopt($ch, CURLOPT_NOSIGNAL, 1);
        curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 5000);
        curl_setopt($ch, CURLOPT_HTTPHEADER, array('Content-Type: application/xml;charset="UTF-8"', 'Accept: application/xml'));
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, true );
        curl_setopt($ch, CURLOPT_POSTFIELDS,"$this->xml_data" );
        $this->result = curl_exec($ch);
        $this->errno = curl_errno($ch);
        $this->info = curl_getinfo($ch);
        $this->httpStatusCode = $this->info["http_code"];
        curl_close($ch);
        return $this->ParseResponse();
    }
csandazoltan commented 4 years ago

@szecsenyizoltan ugyanezekkel a paraméterekkel result: image

errno = 0

info: image

httpStatusCode = 200

Átváltok másik felhasználóra és már van letöltés: image

csandazoltan commented 4 years ago

Érdekességet fedeztünk fel. A válasz méretével lesz probléma, most a mai napon még csak 3 számla van kiállítva, azok lejönnek, a tegnapi nap nem, 07-05 megint jó 5 számlával.

Nem tudom eldönteni, hogy nálunk van e a probléma, vagy a küldő oldalon, mert nem csak nekem van ilyen bajom.

Mindenesetre, ma figyelni fogjuk a választ és megpróbáljuk azonosítani azt a pontot amikor már a curl azt mutatja, hogy üres. (Ha tippelnem kéne az első oldal végén.)

A kimenő számlák response már üres A bejövő még van 9 számlánál

Mondjuk azt meg kell mondanom, hogy a szecsenyizoltan által felvetett 20.04 ubuntu verzió alatt, megy a lekérés.

Szerintem jó lenne kitalálni hol csúszik el a dolog, rosszul küldjök a kérést, vagy a választ rosszul értelmezi, vagy van a válaszban valami aminek nem kéne ott lennie. a 18.04.4 LTS még mindig aktív support-ban van, nem kevesen használják.

csandazoltan commented 4 years ago

Kapás van :)

Az 5 percenkénti lekérdezés az alábbi eredményt hozta: 10:13-kor "kiüresedett a válasz" image

3 számla már nem látszik az "üres válasz miatt" Sikerült megszerezni a tranzakció azonosítókat: 30YTWFZJWWUSPIM7 30YTRQ7A13Q07P4M 30YT5KZOSICE7K5L

Ezeken a számlákon nem csak a queryInvoiceDigest, hanem a queryInvoiceData IS üres.

Ha lekérdezek azok közül a számlák közül amik még megérkeztek, annal van data pl.: "30YSTGL4ESRXYE23"

image

NTCA-supporter commented 4 years ago

Szia @csandazoltan ! Teszt rendszerbe be tudsz küldeni egy számlát ezen 3 közül? Ott ránéznék én is, illetve lehet nektek is jó lenne ránézni, hogy ott hogy viselkedik. Köszi

csandazoltan commented 4 years ago

Ezeket a számlákat nem én küldtem, ezek INBOUND számlák, mások állították ki nekünk

csandazoltan commented 4 years ago

De mindjárt keresek egy kimenő számlát amiről nem tudok adatot visszakérni és beküldöm tesztbe

csandazoltan commented 4 years ago

@NTCA-supporter Nem tudom beküldeni, ennek a cégnek az adatszolgáltatását egy külső cég végzi, a digest-el őket akartuk volna ellenőrizni.

Csak annyi információm van most, hogy a 30UTFBLPSV1XPUOI tranzakciós számon 1. index-en a PVS00887310, számlát le tudom most kérdezni 30V5SWVJIG28SBK7 tranzakciós számon 1. index-en a PVS00887311, számlára a queryInvoiceData "üres" választ ad.

Érdekes módon a queryInvoiceDigest, viszont lehozza a 07-05-ös kimenő számlák listáját, 5db, köztük a fenti PVS00887310 és PVS00887311

era910413 commented 4 years ago

Mi jelenleg a tesztbe és az élesbe is beküldjük a számláinkat, szóval én is tudok írni példát - az élesen a lenti requestId-ra nem kapok semmilyen választ, míg a teszten igen: Éles:

GAEA3A202007084523056 2020-07-07 
<dateTo>2020-07-07</dateTo>

Teszt:

GAE63D202007084533104

Néhány pl számla: 0H/Z3LH6 Tesztben trid: 30X6GP5VI5UBJC9N Éles trid: 30X73KOQFN7JHVA2

0H/Z3LH5 Tesztben trid: 30X6GPMQYRBW69UL Éles trid: 30X73K56KEAYYUKU

csandazoltan commented 4 years ago

Úgy tűnik megoldódott a probléma, CURL-t kellett frissíteni. 7.71 a legfrissebb. Frissítettünk és már nincs üres lekérdezés

A történethez hozzátartoztik, hogy a javaslott biztonságos verzió Ubuntu 18.04.4 LTS Bionic Beaver a CURL oldalán a 7.58. A package manager nem fogja magától frissíteni, a frissítést nekünk kellett kézzel "make"-elni

A 7.68 as verzió amivel már nem volt gond az a 20.04 LTS Focal Fossa verzióhoz ajánlott. image

Lehet a leírásban a jövőben ezt meg lehetne említeni a "Számlázó programokra vonatkozó technikai követelmények" részen, hogy az Ubuntu 18.04 és a hozzá javasolt CURL 7.58-as verzió lekérdezézési problémákat okozhat, javasolt a CURL "kézi" frissítése, legalább 7.68-as verzióra

Köszönjük mindenkinek a segítséget!

@era910413 Nálatok milyen CURL verzió van?

era910413 commented 4 years ago

Nalunk nagyon régi: 7.26.0 A héten szabin van a kolléga aki tud frissebbet felrakni, szóval nekem hétfőig várnom kell :) De megnyugtató, hogy ezzel meg is fog oldódni a probléma.

NTCA-supporter commented 4 years ago

Sziasztok!

Akkor kijelenthető, hogy tisztán kliensoldali a probléma? Zárhatom az issuet?

Köszönöm!

csandazoltan commented 4 years ago

Ami biztos, hogy a CURL 7.58 "nem várt eredményeket hoz", az hogy ezt a viselkedést mi váltja ki azt nem tudjuk. 18.04-el az interakció, valami a küldő oldalon vált ki egy régebbi hibát....

A lényeg, hogy most jönnek az adatok, figyeljük a jövőben.

Viszont akkor is javasoltnak tartom ezt a API leírásában megemlíteni, mert a 18.04.4 még mindig egy aktívan frissített és használt Ubuntu verzió, amiben a 7.58-as curl van és az nem fog automatikusan frissülni.

Mégegyszer köszönöm a segítséget és az információkat mindenkitől!

Lezártam az issue-t :)

Enkiducsa commented 4 years ago

HTTP 200-as válasz queryInvoiceDigest esetén teljesen üres. Szeretnék adatot lekérni queryInvoiceDigest api műveleten keresztül. XSD megfeleltetés szerint a kérés helyes, XML beküldésére 200-as válasz érkezik, de a válasz üres. Nincs hibaüzenet semmilyen válasz. Leírás szerint kapnom kellene xml választ, ha nincs tálalat az idő paramétereknek megfelelően ("availablePage" = 0)

Ma hajnal 3kor még volt válasz de most üres. Érdekesség, hogy van olyan bejelentkezésünk ami viszont ad választ. Tehát egyik felhasználónál működik az API a másiknál nem.

Ma teszteltem. Az Upload-date szerinti lekérdezés hasít a frissítés óta

NTCA-developer commented 4 years ago

Örülünk, köszi a visszajelzést! Szóljatok ha láttok még valami deficitet.