Mnogi učesnici nabavke, bez obzira na iskustvo, suočavaju se s problemom ispravnog rada na elektronskoj trgovačkoj platformi. Ove greške se mogu otkriti u bilo kom trenutku, uključujući i tokom elektronskog trgovanja.
Posledice mogu biti veoma različite, i to:
- Prijava za učešće na konkursu nije predata na vrijeme
- Izgubljena e-aukcija
- Državni ugovor nije potpisan na vrijeme
Tri najčešća problema sa elektronskim potpisom
- Sertifikat učesnika u nabavci nije prikazan na elektronskoj stranici
- Elektronski potpis ne potpisuje dokumente
Zapravo, grešaka može biti mnogo više, ali mi ćemo analizirati glavne i njihove uzroke, te navesti moguće načine otklanjanja problema.
Najvažnije je zapamtiti da za ispravan rad elektroničkog potpisa morate koristiti pretraživač Internet Explorer koji nije niži od verzije 8 i, po mogućnosti, ne viši od 11 (sa verzijom 11 ne postoji garancija stabilnog rada potpisa).
Certifikat ključa za potpisivanje nije vidljiv na web lokaciji kada se pokušava prijaviti
U ovom slučaju greška je nastala iz nekoliko razloga odjednom, a to su:
- Neispravna konfiguracija certifikata ključa za potpisivanje
- Internet pretraživač nije ispravno konfigurisan
- Nedostaje korijenski certifikat tijela za sertifikaciju
Kako riješiti problem?
Prije svega, morate provjeriti jeste li ispravno instalirali otvoreni dio certifikata u osobni putem alata za zaštitu kriptografskih informacija (Crypto Pro). U tom slučaju, verzija instaliranog programa odgovara tipu vašeg operativnog sistema.
Zatim, u postavkama pretraživača Internet Explorer, morate dodati adrese lokacija na pouzdane lokacije i omogućiti sve ActiveX kontrole.
Elektronski potpis daje grešku prilikom potpisivanja dokumenata
Obično se ova greška javlja u nekoliko slučajeva:
- Licenca programa CryptoPro je istekla
- Mediji sa umetnutim drugim sertifikatom
Kako to popraviti?
Da biste to učinili, potrebno je da dobijete novu licencu kontaktiranjem Centra za sertifikaciju. Nakon što je licenca uspješno primljena, potrebno je da pokrenete CryptoPro i unesete serijski broj licence.
U drugom slučaju potrebno je provjeriti sve zatvorene posude (medije) umetnute u USB konektor računara i provjeriti da li je odabran ispravan certifikat.
Sistem daje grešku prilikom ulaska na elektronsku platformu
Ova greška može biti uzrokovana kombinacijom gore navedenih razloga. Kao što pokazuje praksa, takva se greška prije svega pojavljuje zbog pogrešno instalirane Capicomove biblioteke. Preporučujemo vam da provjerite instaliranu biblioteku na vašem računaru i obratite pažnju na potrebu kopiranja 2 sistemske datoteke sa ekstenzijom ..dll u jedan od Windows foldera kada koristite 64-bitni sistem.
Kako biste izbjegli ovakve greške, prije instaliranja elektronskog potpisa pročitajte o instalaciji i konfiguraciji elektronskog potpisa ili nalogu za puštanje i konfiguraciju elektronskog potpisa u našoj kompaniji.
COMET tehnologije omogućavaju organiziranje ažuriranja podataka na stranici bez intervencije korisnika.
Chatovi, Internet mail i višekorisnički administrativni paneli nisu potpuna lista gdje su primjenjivi.
U ovoj seriji članaka detaljno su opisane brojne suptilne tačke i rješenja uobičajenih problema.
Šta je COMET?
COMET (ili "server push") je metoda prijenosa podataka sa servera na klijenta, koju pokreće server.
Na primjer, imate web stranicu za e-trgovinu i menadžer može pratiti konverzije kupaca.
COMET omogućava menadžeru da odmah, online, pita klijenta o nečemu, predloži zanimljivu opciju.
"Server-driven" znači da klijent ne pita samog servera, on samo sjedi na stranici.
Najstariji primjer COMET-a je chat. Osoba samo ostaje na stranici i prima nove poruke.
COMET se također koristi u admin panelima za obavještavanje o promjenama drugih posjetitelja, za zajedničko uređivanje dokumenata itd.
Metode implementacije
Postoji mnogo načina za implementaciju COMET-a. Imaju niz karakteristika, prednosti i mana.
Postoje dvije glavne klase.
Porukom na upit
Pregledač prima svaki događaj na serveru kao poseban zahtjev. Ovdje postoje dvije glavne metode.
- Često glasanje
- Duga anketa
Da bi se smanjio broj veza i potrebno kašnjenje, poruke o događajima se pakuju u posebne pakete, "datagrame".
Na primjer, jedna XML poruka može izgledati ovako:
Prilikom sljedećeg povezivanja, pretraživač odmah prima cijeli paket događaja do danas.
Pregledač održava stalnu vezu sa serverom, takozvanim "kanalom", i preko njega prima događaje.
Komunikacijski kanal se s vremena na vrijeme prekida:
- tako da proxy ne pomisli da je veza istekla i prekine je umjesto nas
- da očistite memoriju od smeća starih poruka
Osim toga, radi mjerenja kašnjenja mreže i kontrole veze, server može periodično slati ping pakete preko ovog kanala.
Glavni načini održavanja trajne veze su:
- Beskrajni IFrame
- XMLHTTPRequest, interaktivno
- Višedijelni XMLHTTPRequest
- Izvor događaja
Naći ćete ih u drugim člancima u ovom dijelu.
Uobičajeni problemi s upornim vezama
HTTP protokol je prvobitno dizajniran tako da jedan zahtjev vraća jednu jedinicu informacija. A mi želimo - mnogo, otuda i neke poteškoće...
Proxy buffering
Ovo je rijetko, ali proxy može baferirati određenu količinu podataka prije slanja klijentu. Na primjer, šaljite i primajte odgovore u 2K blokovima. U tom slučaju, poruke će ostati na proxy serveru i čekati dok se ne otkucaju 2K (ili koja god da je veličina bafera) bajtova, a tek tada će se prenijeti do klijenta.
Rješenje je dodavanje 2K razmaka svakoj poruci.
Nije poznato da li će ovaj problem uticati na vas. Nadam se da nije, ali imajte na umu baferovanje proxyja kao mogući razlog za pritužbe korisnika.
Ne mogu gzip
IFrame koji se koristi za prosljeđivanje poruka NE bi trebao biti komprimiran sa gzip / deflate. Drugim riječima, kompresiju treba onemogućiti za URL servisa poruka.
Omogućena kompresija podrazumijeva da pretraživač čeka da se preuzimanje završi, a zatim ga dekompresuje i prikazuje korisniku. U našem slučaju, to je kategorički kontraindicirano i nemoguće je komprimirati dijelove stranice (poruke) zasebno.
Ovo je neugodna posljedica hakerske prirode iframe-a. Na primjer, u dugoj anketi, kompresija ide s praskom, jer događaji nisu dio iste stranice.
Baferovanje stranica servera
Ne zaboravite isključiti baferovanje servera. Apache / PHP bundle - onemogućite baferovanje izlaza i omogućite ob_implicit_flush:
Dok (@ob_end_flush ()) () ob_implicit_flush (1); // i naravno ukloniti ograničenje za vrijeme izvršavanja skripte set_time_limit (0);
COMET: Česta anketa protiv trajne veze
Kao i uvijek, pri pisanju web aplikacije postavlja se pitanje izbora arhitekture. S jedne strane, rješenja za duge veze (sve osim čestih anketa) omogućavaju brzo obavještavanje. S druge strane... Da li je duga veza uvijek bolja od čestih anketa?
Rješenje s dugim priključcima je naizgled optimalnije, ali mnogo kompliciranije i ima niz karakteristika.
- Implementacija duge veze ima tendenciju da zakomplikuje arhitekturu. Možda bi se moglo koristiti jednostavnije rješenje?
- Brojni web serveri su loše optimizirani za veliki broj dugih konekcija. Na primjer, koriste se niti ili procesi koji troše fiksnu količinu resursa i ne puštaju ih do kraja veze. Na nivou OS-a problem se rješava korištenjem kqueue (FreeBSD) ili epoll (Linux). Na webu nivo servera, možete koristiti
- Apache MPM događaj za apache 2.2 (eksperimentalni i ograničeni MPM, posebne ručke niti Slušanje i Keep-Alive utičnice)
ne radi dobro sa mod_perl / mod_php - Jetty (Java) / Twisted (Python), nginx i drugi specijalizovani serveri sa jednom niti / procesom za mnoge klijente.
Hoće li trenutna serverska arhitektura podnijeti duge veze? Odgovor nije očigledan za stotine/hiljade istovremenih veza, ali recimo da je do 100 veza u bilo kojoj arhitekturi u redu.
- Apache MPM događaj za apache 2.2 (eksperimentalni i ograničeni MPM, posebne ručke niti Slušanje i Keep-Alive utičnice)
- Koliko dugo su korisnici na istoj stranici? Tokom prijelaza, veza će se najvjerovatnije u svakom slučaju morati ponovo otvoriti.
- Ako su kašnjenja u isporuci događaja prihvatljiva, onda će možda biti dovoljno često glasanje?
Klasični (transportno nezavisan) model COMET
Pogledajmo interakciju klijent-server "iz ptičje perspektive", iznad detalja prenosa podataka, transporta itd. Na primjer, to se radi u specijaliziranom server-push engine lightstreamer-u.
Serverske veze se dijele na dva tipa
- Kontrolna veza - kontrolne veze preko kojih klijent šalje zahtjeve serveru. Ovo su redovni AJAX zahtjevi putem XMLHTTPRequest-a.
- Push veza (kanal) - tok događaja, veza preko koje klijent prima događaje od servera
Svi događaji na serveru imaju tip. Klijent se može pretplatiti i odjaviti na događaje od interesa putem kontrolnih veza. Radi praktičnosti, tipovi su organizirani prema dijagramima. Na primjer, šema razgovora može biti tipa poruka.
Na primjer, sljedeći dijagram opisuje tipičan slijed radnji:
- Klijent otvara streaming vezu sa serverom
- Klijent se pretplaćuje na događaje tipa Item1 u Shemi1
- Server šalje događaje
- Klijent se odjavljuje sa događaja putem nove kontrolne veze
- Klijent zatvara vezu
Ili - evo složenijeg dijagrama u kojem se klijent pretplaćuje na različite vrste događaja:
Lightstreamer koristi iframe kao transport. Potrebno ga je s vremena na vrijeme zatvoriti kako bi se počistili primljeni predmeti. Kada se sesija zatvori (ovo se dešava i kada se stranica osvježi u pretraživaču), server baferuje nove događaje do određenog vremenskog ograničenja i šalje ih čim se otvori nova sesija Stream Connection 2 istog korisnika.
Općenito, baferovanje događaja je opća tehnika koja vam omogućava da lagano preživite zatvaranje veze i potrebna je za bilo koji transport.
U novom formatu za skladištenje, datoteka evidencije može biti do stotine gigabajta. Vrijeme uzorkovanja za njega će biti jako dugo i javlja se problem: rad svih korisnika prestaje.
Znaci ovog problema su:
Nemoguće je ući u infobazu.
Gotovo 100% aktivnosti diska na kojem se nalazi dnevnik i aktivno čitanje datoteke evidencije od strane rmngr procesa.
Ova stavka se može provjeriti pomoću monitora resursa (Task Manager - Performance - Open Resource Monitor) na kartici "Disk".
U grupi „Uređaji za skladištenje“ obratite pažnju na kolonu „Aktivno vrijeme (%)“.
U grupi „Aktivnost diska“ morate obratiti pažnju na kolone „Čitanje“ i „Datoteka“. Može se sortirati po koloni "Čitanje". rmngr proces će biti među prvim redovima s maksimalnom brzinom čitanja. Zatim morate pogledati ime datoteke koja se čita, ona će odgovarati dnevniku određene baze podataka.
U administrativnoj konzoli klastera 1C: Enterprise servera na listi sesija, skoro svi korisnici će imati veliku i približno istu vrijednost u koloni „Shvaćeno od DBMS“ ili u koloni „Vrijeme poziva (trenutno)“.
Ako se pronađe problem, potrebno je da:
Zapamtite UID IB-a kojem rmngr proces čita.
Započnite prikupljanje tehnološkog dnevnika za EXCP događaje, ako već nisu započeli.
Izvezite sve sesije na problem servera ILI na problematičnu informacijsku sigurnost koristeći administrativnu konzolu klastera 1C: Enterprise servera, u slučaju da su potrebni dodatni podaci za analizu.
Ponovo pokrenite uslugu 1C: Enterprise.
Prikupite tehnološki dnevnik u trenutku ponovnog pokretanja servera 1C: Enterprise.
Analizirajte tehnološki dnevnik: potražite riječi “UnloadLogRegister” ili “UnloadEventLog”.
primjer:
29: 40.069000-0, EXCP, 4, proces = rphost, p: ProcesName = ib_accounting , t: clientID = 114396, t: applicationName = 1CV8C, t: ComputerName = COMP , t: connectID = 109127, ID sesije = 1, Usr = IvanovII , AppID = 1CV8C, ClientID = 114389, Exception = NetDataExchangeException, Descr = Prijenos podataka je prekinut na inicijativu strane koja prima., Kontekst = "Form.Call: ExternalReport.RegisterLog Analysis.Form.Module.BackgroundJob
GeneralForm.ReportForm.Form: 1242: Variants Report.GenerateReportIn the Background (ReportFormationParameters, BackgroundJobResult.ResultAddress);
GenericModule.Report Options.Module: 2544: Generacija = GenerateReport (Parameters, False, False);
GenericModule.Report Options.Module: 2060: ReportObject.ComposeResult (Result.TableDocument, Result.Explanation);
ExternalReport.AnalysisLoginRegister.Object Module: 64:UploadJournalRegistration(TK, Izbor, Kolone); "
Na ovoj liniji možete reći ko: IvanovII, gdje (na kom kompjuteru): COMP , u kojoj infobazi: ib_accounting izvršio analizu dnevnika.
