Wielu naszych klientów, dla których przygotowaliśmy rozwiązanie służące do raportowania do ZSMOPL (producenci leków, hurtownie oraz grupa aptek) testuje od kilku miesięcy wysyłki komunikatów xml na środowisku testowym ZSMOPL, a niektórzy zdecydowali się korzystać już ze środowiska produkcyjnego.
Niestety bardzo często w ostatnim czasie (jakieś 3 tygodnie) oba te środowiska działają niestabilnie, to znaczy:
– czasem oba webserwisy są niedostępne (wyłączone)
– czasem jeden działa (testowy), a drugi nie (produkcyjny)
– czasem webserwis przyjmuje komunikat, ale nie nadaje mu numeru, za to zgłasza błąd serwera ZSMOPL (tak było od 22.01 do końca lutego) jak poniżej:
(faultcode>soap:Server):
soap:Serverjavax.jms.JMSExce
ption: Wire format negotiation timeout: peer did not send his wire format.;
nested exception is javax.jms.IllegalStateException: javax.jms.JMSException:
Wire format negotiation timeout: peer did not send his wire
format.
– przeglądanie komunikatów na portalu ZSMOPL testowym (przeglądanie błędów) trwa bardzo długo
– dodatkowo od wczoraj (5.02) webserwis produkcyjny jest włączony, ale nie przyjmuje komunikatów (czekaliśmy po wysyłce 2 godziny i webserwis nie dał żadnej odpowiedzi)
Wszystkie powyższe „niedogodności” uniemożliwiają planowanie i realizację prac związanych ze spełnieniem wymogu raportowania do ZSMOPL.
Ponadto, jeśli wykonawca ZSMOPL wykonuje jakieś prace serwisowe na środowiskach: testowym i produkcyjnym, co powoduje istotne ograniczenia w ich dostępności, to takie działania powinny być ogłaszane z wyprzedzeniem – tak, żeby CSIOZ mógł opublikować komunikat o pracach serwisowych na swojej stronie.