Shumë pjesëmarrës të prokurimit, pavarësisht përvojës, përballen me problemin e punës korrekte në platformën e tregtimit elektronik. Këto gabime mund të zbulohen në çdo kohë, përfshirë edhe gjatë procesit të tregtimit elektronik.
Pasojat mund të jenë shumë të ndryshme, domethënë:
- Nuk është dorëzuar në kohë aplikimi për pjesëmarrje në konkurs
- Ankandi elektronik i humbur
- Kontrata shtetërore nuk është nënshkruar në kohë
Tre problemet më të zakonshme në punën me një nënshkrim elektronik
- Certifikata e pjesëmarrësit në prokurim nuk shfaqet në platformën elektronike
- Nënshkrimi elektronik nuk nënshkruan dokumente
Në fakt, mund të ketë shumë më tepër gabime, por ne do të analizojmë shkaqet kryesore dhe shkaqet e tyre, si dhe do të përshkruajmë mënyrat e mundshme për të rregulluar problemet.
Gjëja më e rëndësishme është të mbani mend se që nënshkrimi elektronik të funksionojë siç duhet, duhet të përdorni Internet Explorer të paktën versionin 8 dhe, mundësisht, jo më të lartë se 11 (me versionin 11 nuk ka garanci që nënshkrimi do të funksionojë i qëndrueshëm).
Certifikata e çelësit të nënshkrimit nuk është e dukshme në sajt kur përpiqeni të identifikoheni
Në këtë rast, gabimi shkaktohet nga disa arsye njëherësh, përkatësisht:
- Konfigurim i gabuar i certifikatës së çelësit të nënshkrimit
- Shfletuesi i internetit është konfiguruar gabimisht
- Mungon certifikata rrënjësore e autoritetit të certifikimit
Si të zgjidhet problemi?
Para së gjithash, duhet të siguroheni që e keni instaluar saktë pjesën publike të certifikatës në pjesën personale përmes CIPF (Crypto Pro). Në këtë rast, versioni i programit të instaluar është i përshtatshëm për llojin e sistemit tuaj operativ.
Më pas, në cilësimet e shfletuesit Internet Explorer, duhet të shtoni adresat e faqeve në sajtet e besuara dhe të aktivizoni të gjitha kontrollet ActiveX.
Nënshkrimi elektronik jep një gabim gjatë nënshkrimit të dokumenteve
Në mënyrë tipike, ky gabim ndodh në një numër rastesh:
- Licenca CryptoPro ka skaduar
- Media e futur me një certifikatë tjetër
Si ta rregulloni atë?
Për ta bërë këtë, ju duhet të merrni një licencë të re duke kontaktuar Autoritetin e Certifikimit. Pasi të jetë marrë me sukses licenca, duhet të nisni CryptoPro dhe të vendosni numrin serial të licencës.
Në rastin e dytë, duhet të kontrolloni të gjithë kontejnerët (bartës) të mbyllur të futur në portën USB të kompjuterit dhe të kontrolloni nëse është zgjedhur certifikata e saktë.
Sistemi jep një gabim kur hyn në platformën elektronike
Ky gabim mund të shkaktohet nga një kombinim i arsyeve të listuara më sipër. Siç tregon praktika, një gabim i tillë shfaqet kryesisht për shkak të një biblioteke Capicom të instaluar gabimisht. Ju rekomandojmë që të kontrolloni praninë e bibliotekës së instaluar në kompjuterin tuaj dhe t'i kushtoni vëmendje nevojës për të kopjuar 2 skedarë të sistemit me shtesën .dll në një nga dosjet e Windows kur përdorni një sistem 64-bit.
Në mënyrë që ju të shmangni gabime të tilla, përpara se të instaloni një nënshkrim elektronik, lexoni instalimin dhe konfigurimin e një nënshkrimi elektronik ose porositni një lëshim dhe konfigurim të një nënshkrimi elektronik në kompaninë tonë.
Teknologjitë COMET ju lejojnë të organizoni përditësimin e të dhënave në faqe pa ndërhyrjen e përdoruesit.
Bisedat, posta në internet dhe administratorët me shumë përdorues janë larg një liste të plotë ku ato janë të zbatueshme.
Në këtë seri artikujsh, përshkruhen në detaje pika të shumta delikate dhe zgjidhje për problemet e zakonshme.
Çfarë është COMET?
COMET (ose "shtytje serveri") është një metodë e transferimit të të dhënave nga një server në një klient, e iniciuar nga serveri.
Për shembull, ju keni një dyqan elektronik dhe menaxheri mund të gjurmojë tranzicionet e klientëve.
COMET lejon menaxherin që menjëherë, në internet, të pyesë klientin për diçka, të ofrojë një opsion interesant.
"Iniciuar nga serveri" do të thotë që vetë klienti nuk kërkon serverin, ai është vetëm në faqe.
Shembulli më i vjetër i COMET është chat. Personi është vetëm në faqe dhe merr mesazhe të reja.
COMET përdoret gjithashtu në panelet e administratorit për të njoftuar vizitorët e tjerë për ndryshimet, për redaktimin e përbashkët të dokumenteve, etj.
Metodat e zbatimit
Ka shumë mënyra për të zbatuar COMET. Ata kanë një sërë karakteristikash, avantazhesh dhe disavantazhesh.
Ka dy klasa kryesore.
Sipas kërkesës
Shfletuesi merr çdo ngjarje në server me një kërkesë të veçantë. Këtu ka dy metoda kryesore.
- Sondazhi i shpeshtë
- Sondazh i gjatë
Për të zvogëluar numrin e lidhjeve dhe vonesave të nevojshme, mesazhet e ngjarjeve paketohen në pako të veçanta, "datagrame".
Për shembull, një mesazh XML mund të duket si:
Në lidhjen tjetër, shfletuesi merr menjëherë të gjithë paketën e ngjarjeve deri më sot.
Shfletuesi mban një lidhje të përhershme me serverin, të ashtuquajturin "kanal", dhe merr ngjarje përmes tij.
Kanali i komunikimit prishet herë pas here:
- që proxy të mos mendojë se ka ardhur koha e lidhjes dhe të mos na e prishë
- për të pastruar kujtesën e plehrave të mesazheve të vjetra
Përveç kësaj, për të matur vonesat në rrjet dhe për të kontrolluar lidhjen, serveri mund të dërgojë periodikisht paketa ping mbi këtë kanal.
Mënyrat kryesore për të mbajtur një lidhje të vazhdueshme:
- Infinite IFrame
- Kërkesë XMLHTTPR, interaktive
- Kërkesë shumëpjesëshe XMLHTTPR
- ngjarje-burim
Do t'i gjeni në artikuj të tjerë në këtë seksion.
Çështje të përbashkëta të vazhdueshme të lidhjes
Protokolli HTTP fillimisht u krijua në mënyrë që një kërkesë të kthente një pjesë të informacionit. Dhe ne duam - shumë, prandaj disa vështirësi ...
Proxy Buffering
Kjo është e rrallë, por përfaqësuesi mund të ruajë një sasi të caktuar të dhënash përpara se t'ia kalojë klientit. Për shembull, për të marrë dhe për të dhënë një përgjigje në blloqe prej 2K. Në këtë rast, mesazhet do të mbeten në proxy dhe do të presin derisa të jenë 2K (ose cilado qoftë madhësia e buferit) bajt, dhe vetëm atëherë ato do t'i transmetohen klientit.
Zgjidhja është të shtoni 2K hapësira në çdo mesazh.
Nuk dihet nëse kjo çështje ju prek. Shpresoj që jo, por të kesh parasysh bufferimin e proxy si një arsye e mundshme për ankesat e përdoruesve është një domosdoshmëri.
Nuk mund të gzip
Një IFrame që përdoret për të dërguar mesazhe NUK duhet të kompresohet me gzip/deflate. Me fjalë të tjera, kompresimi duhet të çaktivizohet për mesazhet URL të shërbimit.
Kompresimi i aktivizuar do të thotë që shfletuesi pret fundin e shkarkimit dhe më pas e dekompreson dhe ia tregon përdoruesit. Në rastin tonë, kjo është kategorikisht kundërindikuar, dhe është e pamundur të kompresohen pjesët e një faqeje (mesazhi) veç e veç.
Kjo është një pasojë fatkeqe e natyrës hakere të iframe. Për shembull, në një sondazh të gjatë, kompresimi është i madh, sepse ngjarjet nuk janë pjesë e së njëjtës faqe.
Buferimi i faqes së serverit
Mos harroni të çaktivizoni bufferimin e serverit. Në Apache/PHP - çaktivizoni bufferimin e daljes dhe aktivizoni ob_implicit_flush:
Ndërsa (@ob_end_flush()) () ob_implicit_flush(1); // dhe sigurisht, hiqni kufirin për kohën e ekzekutimit të skriptit set_time_limit(0);
COMET: Sondazh i shpeshtë VS lidhje e vazhdueshme
Si gjithmonë, kur shkruani një aplikacion në internet, lind pyetja e zgjedhjes së arkitekturës. Nga njëra anë, zgjidhjet për lidhjet e gjata (çdo gjë përveç sondazheve të shpeshta) ofrojnë njoftim të shpejtë. Nga ana tjetër... A është gjithmonë më mirë një lidhje e gjatë sesa një sondazh i shpeshtë?
Zgjidhja me lidhje të gjata duket të jetë më optimale, por është shumë më e ndërlikuar dhe ka një sërë veçorish.
- Zbatimi i një lidhjeje të gjatë, si rregull, e ndërlikon arkitekturën. Ndoshta mund t'ia dilni me një zgjidhje më të thjeshtë?
- Një numër i serverëve në internet janë optimizuar dobët për një numër të madh lidhjesh të gjata. Për shembull, përdoren threads ose procese që hanë një sasi fikse burimesh dhe nuk i lëshojnë ato deri në fund të lidhjes. Në nivelin e OS, problemi zgjidhet duke përdorur kqueue (FreeBSD) ose epoll (Linux). niveli i serverit të uebit, mund të përdorni
- Ngjarja Apache MPM për apache 2.2 (MPM eksperimentale dhe e kufizuar, doreza speciale të temave Listening dhe Keep-Alive fole)
nuk funksionon siç duhet me mod_perl/mod_php - Jetty (Java) / Twisted (Python), nginx dhe serverë të tjerë të specializuar me një thread/proces për shumë klientë.
A do të trajtojë arkitektura aktuale e serverit lidhje të gjata? Përgjigja nuk është e qartë për qindra/mijëra lidhje të njëkohshme, por le të themi se deri në 100 lidhje në çdo arkitekturë është mirë.
- Ngjarja Apache MPM për apache 2.2 (MPM eksperimentale dhe e kufizuar, doreza speciale të temave Listening dhe Keep-Alive fole)
- Sa kohë qëndrojnë përdoruesit në të njëjtën faqe? Gjatë tranzicioneve, lidhja me shumë mundësi do të duhet të rihapet gjithsesi.
- Nëse vonesat në shpërndarjen e ngjarjeve janë të pranueshme, atëherë ndoshta do të mjaftojë një sondazh i shpeshtë?
Modeli COMET klasik (i pavarur nga transporti).
Le të bëjmë një pamje nga syri i ndërveprimit klient-server, mbi detajet e transferimeve të të dhënave, transporteve, etj. Për shembull, kjo është mënyra se si bëhet në transmetimin e specializuar të motorit me shtytje të serverit.
Lidhjet e serverëve ndahen në dy lloje
- Lidhja e kontrollit - lidhjet kontrolluese përmes të cilave klienti dërgon kërkesa në server. Këto janë kërkesa normale AJAX nëpërmjet XMLHTTPRequest.
- Push Connection(channel) - rrymë ngjarjesh, lidhje përmes së cilës klienti merr ngjarje nga serveri
Të gjitha ngjarjet në server kanë një lloj. Një klient mund të abonohet dhe çabonohet në ngjarjet me interes për të nëpërmjet lidhjeve të kontrollit. Për lehtësi, llojet janë të organizuara sipas skemave. Për shembull, në skemën e bisedës, lloji i mesazhit mund të jetë.
Për shembull, diagrami i mëposhtëm përshkruan një rrjedhë tipike pune:
- Klienti hap një lidhje transmetimi me serverin
- Klienti pajtohet në ngjarje të tipit Item1 në Schema1
- Serveri dërgon ngjarje
- Klienti çabonohet nga ngjarjet nëpërmjet lidhjes së re të kontrollit
- Klienti mbyll lidhjen
Ose - këtu është një diagram më kompleks në të cilin klienti tashmë pajtohet në lloje të ndryshme ngjarjesh:
Lightstreamer përdor një iframe si një transport. Herë pas here duhet të mbyllet për të pastruar objektet e marra. Kur sesioni mbyllet (e njëjta gjë ndodh kur faqja rifreskohet në shfletues), serveri ruan ngjarjet e reja deri në një kohë të caktuar dhe i dërgon ato sapo të hapet një sesion i ri Stream Connection 2 i të njëjtit përdorues.
Në përgjithësi, bufferimi i ngjarjeve është një teknikë e zakonshme që ju lejon të mbijetoni butësisht pas mbylljes së një lidhjeje dhe është e nevojshme për çdo transport.
Në formatin e ri të ruajtjes, skedari i regjistrit mund të jetë qindra gigabajt. Koha e marrjes së mostrave për të do të jetë shumë e madhe dhe lind një problem: puna e të gjithë përdoruesve ndalon.
Simptomat e këtij problemi janë:
Nuk mund të hyjë në bazën e informacionit.
Pothuajse 100% aktivitet në diskun ku ndodhet regjistri dhe leximi aktiv i skedarit log nga procesi rmngr.
Ky artikull mund të kontrollohet duke përdorur monitorin e burimeve (Task Manager - Performance - Open Resource Monitor) në skedën "Disk".
Në grupin "Pajisjet e kujtesës", kushtojini vëmendje kolonës "Koha aktive (%).
Në grupin "Operacioni i diskut", duhet t'i kushtoni vëmendje kolonave "Lexo" dhe "File". Mund të renditet sipas kolonës "Leximi". Ndër rreshtat e parë me shpejtësinë më të lartë të leximit do të jetë procesi rmngr. Tjetra, duhet të shikoni emrin e skedarit që lexohet, ai do të korrespondojë me regjistrin e regjistrimit të një infobaze specifike.
Në tastierën e administrimit të grupit të serverëve 1C: Enterprise, në listën e seancave, pothuajse të gjithë përdoruesit do të kenë një vlerë të madhe dhe afërsisht të njëjtë në kolonën "DBMS captured" ose në kolonën "Koha e thirrjes (aktuale)".
Kur zbulohet një problem:
Mbani mend UID-in e IB që lexohet nga procesi rmngr.
Filloni mbledhjen e regjistrit teknologjik për ngjarjet EXCP, nëse nuk ka filluar tashmë.
Kryeni një eksportim të të gjitha sesioneve në serverin problematik OSE në IS problematik duke përdorur konsolën e administrimit të grupit të serverëve 1C: Enterprise, në rast se nevojiten të dhëna shtesë për analizë.
Rinisni shërbimin 1C: Enterprise.
Mblidhni një regjistër teknologjik për kohën e rifillimit të serverit 1C:Enterprise.
Analizoni regjistrin e teknologjisë: kërkoni për fjalët "Shkarko Regjistrin" ose "UnloadEventLog".
Shembull:
29:40.069000-0,EXCP,4,procesi=rphost, p:processName=ib_accounting ,t:clientID=114396,t:ApplicationName=1CV8C, t:Emri i kompjuterit=COMP ,t:connectID=109127,SessionID=1, Usr=IvanovII ,AppID=1CV8C,ClientID=114389,Exception=NetDataExchangeException,Descr=Transferimi i të dhënave u ndërpre me iniciativën e palës marrëse.,Context="Form.Call: ExternalReport.Logbook Analysis.Form.Module.BackgroundJobRun
GeneralForm.ReportForm.Form: 1242:ReportVariants.GenerateReportInBackground(Raporto GenerationParameters, BackgroundJob Result.ResultAddress);
GeneralModule.ReportVariants.Moduli: 2544: Generation = GenerateReport(Parametrat, False, False);
GeneralModule.Raport Options.Moduli: 2060: ReportObject.ComposeResult(Rezultati.SpreadsheetDocument, Result.Decryption);
ExternalReport.Log Analysis.ObjectModule: 64:Ngarko MagazineRegjistrimi(TK, Zgjedhja, Kolonat);"
Ky rresht tregon se kush: Ivanov II, ku (në cilin kompjuter): KOMP , në të cilën infobazë: ib_accounting filloi analiza e regjistrave.
