1c företags tunn klient. Publikationer. Lägger till en ny databas

2016-12-07T18:05:29+00:00

Många 8 användare har redan hört termer som "Tjock klient" och "Tunn klient". Men få människor vet vad detta betyder.

Fet klient– Det här är det normala sättet att arbeta med programmet. Vi har länge varit vana vid det (sedan dagarna 7.7 och 8.2). I detalj .

Tunn klient- detta är 1C-startläget för att arbeta via Internet, när redovisningsdatabasen inte finns på vår dator eller ens i vårt nätverk, utan någonstans tusentals kilometer bort på en fjärrserver (möjligen i en annan stad eller ett annat land). I detalj .

Enkelt uttryckt, för en vanlig revisor som arbetar med en databas direkt på sin dator eller på ett företagsnätverk är det ingen skillnad mellan en tunn och en tjock klient.

Men det händer ofta att vissa fel dyker upp i en klient och saknas i en annan. Som till exempel med att visa transaktioner i 1C Accounting 8.3.

I det här fallet kan det vara användbart att ta reda på vilken klient vi för närvarande arbetar i och ändra den till en annan.

Hur vet du vilken kund du arbetar med? Titta på fönstret med versionen av din 1C (i artikeln):

Där, i avsnittet "Ansökan", kommer din klient att indikeras:

Det skrivs om hur man ändrar en klient.

Med vänlig hälsning, (lärare och utvecklare).

för plattform 8.2:

för plattform 8.3:

Kommentar. Automatisk uppdatering av en tunn klient under Windows XP och Windows Vista via 1C:Link kanske inte fungerar. Detta är inte särskilt bekvämt och vi rekommenderar att du överväger att uppgradera till ett mer modernt operativsystem.

Konfigurera 1C Thin Client för att fungera med 1C: Enterprise 8-plattformen version 8.3.4.437 och senare

Installera rotcertifikatet för tjänsten 1C: Link i Windows certifikatarkiv enligt instruktionerna för webbläsaren Internet Explorer.

https://<ваш-сайт>.link.1c.ru/xxx

Välj "Windows-certifikat" som metod för att verifiera servercertifikatet.

Klicka på "Klar"

Ställa in automatisk auktorisering på webbservern

  • Välj önskad informationssäkerhet i 1C Thin Client och klicka på knappen "Ändra".
  • Klicka på länken "Avancerat" (finns under adressfältet i infobasen)
  • I avsnittet "Välj en webbserveranvändarautentiseringsmetod", välj "Välj automatiskt" och klicka på "Nästa".
  • I fönstret för certifikatinställningar klickar du på "Nästa".
  • I avsnittet "Ytterligare startparametrar" anger du raden: där login är webbserverns användarinloggning och lösenord är hans lösenord.

Klicka på "Slutför"-knappen och kontrollera kopplingen till infobasen.

Läs mer om Thin Client-inställningarna på ITS hemsida.

Konfigurera 1C Thin Client för att fungera med 1C: Enterprise 8-plattformen version 8.2.19.121 och senare

För att arbeta i en tunn klient, ladda ner . Spara istället <1C>\bin\cacert.pem , var<1C> - installationskatalogen för 1C Thin Client. Detta kommer att förhindra att SSL-felet "Peer-certifikat kan inte autentiseras med kända CA-certifikat" visas.


Ange namnet på infobasen, välj "Webbserver" och klicka på "Nästa"

Ange adressen till din infobas: https://<ваш-сайт>.link.1c.ru/xxx, där xxx är sökvägen för din webbapplikation.

Klicka på "Klar"

Konfigurera 1C Thin Client för att fungera med 1C: Enterprise 8-plattformsversionerna som inte ingår i listan över rekommenderade

Om du vill använda en annan version av tunn klient än de som rekommenderas ovan för att fungera i tjänsten 1C: Link kan du behöva konfigurera arbetet enligt HTTP eller installation STunnel.

Konfigurera den tunna klienten för att fungera via HTTP

Länkagenten har förmågan att arbeta i en tunn klient med hjälp av HTTP-protokollet. Det föredragna protokollet för att arbeta i en tunn klient via 1C:Link är dock HTTPS. Det rekommenderas inte att använda http-protokollet, eftersom data överförs okrypterat när det används och kan fångas upp av en angripare.

Om du är säker på behovet av att använda detta protokoll för att arbeta i en tunn klient genom tjänsten 1C:Link, kan du använda instruktionerna nedan:

    Öppna länkagentens kontrollpanel och aktivera arbete via HTTP (avsnitt 4.4 i användarmanualen för 1C:Link).

    Konfigurera den tunna klienten:

Starta den tunna klienten och klicka på knappen Lägg till.


Ange namnet på infobasen, välj "Webbserver" och klicka på "Nästa"

Ange adressen till din infobas: http://<ваш-сайт>.link.1c.ru/xxx, där xxx är sökvägen för din webbapplikation.

Klicka på "Klar"

Installation och konfiguration av Stunnel

Installera programmet Stunnel på en dator med en 1C Thin Client. När du har installerat programmet, kör det.

I fönstret som öppnas väljer du "Konfiguration"

I rullgardinsmenyn väljer du "Redigera stunnel.conf"

Anteckningar öppnas med konfigurationsfilen. Ersätt texten i filen med följande rader.

Från och med version 8.2 fick 1C-programmet möjligheten att arbeta i tunt klientläge, vilket har begränsad funktionalitet. Trots det faktum att ganska mycket tid har gått sedan uppdateringen släpptes, förstår ett stort antal användare fortfarande inte helt varför denna innovation är nödvändig, i vilka situationer den är effektiv att använda och vad är skillnaden. I det här materialet kommer vi att prata i detalj om vad den tunna 1C-klienten är, dess fördelar och nackdelar, samt hur man arbetar med den.

Vad är en "tunn klient"?

För att förstå funktionaliteten hos denna programklient måste du förstå varför den kallas "tunn". Svaret på denna fråga är ganska enkelt och ligger i det faktum att detta driftsätt är mycket begränsat i sina möjligheter jämfört med den "tjocka" versionen.

Applikationens "tunna klient" har en mer begränsad uppsättning inbyggda språktyper, som uteslutande är avsedda för att överföra data och ändra den. Allt relaterat till att arbeta med databasen exekveras på servern i detta fall. Med hjälp av denna version av applikationen utvecklas ett hanterat 1C-gränssnitt, vilket gör att du kan optimera företagets arbete.

1C "tunna klienter" kan ta emot färdiga data via en webbanslutning, som redan har förberetts på serversidan.

Dessutom är användningen av denna typ av applikation möjlig med hjälp av en av tre tekniker:

  • Via webben (med en Internetanslutning);
  • Via TCP/IP-protokoll (klient-servertyp);
  • Direkt med databasen.

Internet anslutning

Den "tunna klienten" har förmågan att interagera med programmet "1C: Enterprise" med hjälp av en webbanslutning till Internet. I det här fallet sker arbete med en speciellt konfigurerad webbserver som använder http-dataöverföringsprotokollet. Själva webbservern fungerar dock med programmet 1C: Enterprise via TCP/IP-protokollet eller direkt.

Viktigt: du måste använda ett av följande system som webbservrar:

  • Apache;

Klient-server-anslutning

I det här fallet ansluter tunna klienter till servrar direkt med hjälp av TCP/IP-dataöverföringsprotokollet.

Direkt anslutning till databasen

I det här fallet finns det en direkt interaktion mellan klienten och applikationsdatabasen. För att organisera detta arbetsschema skapas en speciell miljö på datorn där klienten är installerad, som från programmets synvinkel uppfattas som en server. För att organisera det måste du:

  • Ladda ner de nödvändiga serverfilerna till din dator;
  • Ladda applikationskonfiguration.

Fördelarna med en tunn klient

Om vi ​​lägger processtekniken åt sidan och går vidare till de omedelbara fördelarna som att använda den här versionen av 1C-klienten kan vi lyfta fram flera allvarliga fördelar. Dessa inkluderar:

  • Rörlighet;
  • Minska belastningen på kommunikationskanalen;
  • Minsta systemkrav;
  • Att minska företagets kostnader.

Rörlighet

Hårdvaran "tunn klient" gör att användaren kan befinna sig var som helst i världen, så länge det finns en Internetanslutning. Anta till exempel att prefekten för en avdelning är på semester utomlands. För att kunna fatta något viktigt beslut måste han bekanta sig med de senaste rapporteringsuppgifterna. Den fullständiga versionen av applikationen kräver en lokal nätverksanslutning, varför den "tunna klienten" i detta fall kommer till undsättning. Det låter dig arbeta med databasen med en vanlig Internetanslutning.

Ett annat exempel. Ibland, när du gör transaktioner i en filial som inte har en anslutning till det lokala nätverket, till exempel i ett företagslager, är det nödvändigt att ladda ner data från lagerdatabasen för efterföljande laddning till ekonomiavdelningen.

Naturligtvis tar sådana manipulationer tid och orsakar olägenheter. "Tunna klienter" används just för att förenkla sådana uppgifter. Om du har en webbanslutning kan du enkelt överföra data till en gemensam 1C-databas direkt från lagret.

Dessutom använder "tunna klienter" en nätverkskanal enbart för dataöverföring. Den fullständiga versionen av applikationen använder den också för att överföra tjänstdata som är nödvändig för driften av programvaran, vilket minskar kanalens användbara bandbredd.

Således låter "tunna klienter" dig arbeta i 1C-programmet där det inte finns någon webbanslutning med bra bandbredd.

Låga systemkrav

Situationen är liknande med systemkraven för programmet. För att köra den fullständiga versionen krävs kraftfullare datorer, eftersom applikationen använder systemets processor och RAM. "Tunna klienter" 1C är mycket mindre krävande för resurserna på en persondator. Detta är vad som gör att den kan användas även på svaga system.

Att minska företagets kostnader

Denna punkt följer av alla de föregående. På grund av det faktum att utvecklingen av ett hanterat gränssnitt gör att du kan optimera arbetsflödet, spara tid och resurser för företaget, leder detta till en minskning av företagets totala kostnader för redovisning.

Nackdelar med den tunna klienten

Naturligtvis har varje mynt en nackdel. Den "tunna klienten" har också vissa olägenheter och begränsningar, som inte kan ignoreras. Dessa inkluderar:

  • Krav på en kraftfull server;
  • Begränsad funktionalitet;
  • Ovanligt gränssnitt.

Kräver en kraftfull server

Om ett stort antal "tunna klienter" interagerar med huvudservern via en webbanslutning kommer den att utsättas för en ganska stor belastning, vilket ställer vissa tekniska krav. Men att använda den fullständiga versionen av programmet laddar inte mycket mindre, så denna nackdel är mycket relativ.

Begränsad funktionalitet

Som nämnts ovan har lättversionen av applikationen mycket begränsad funktionalitet. Det är till exempel inte möjligt att arbeta i läget "Konfigurator".

Gränssnitt

Denna nackdel försvinner gradvis med tiden och med släppandet av uppdateringar, men till en början vägrade många företag att använda "tunna klienter" eller försökte undvika det just för att applikationsgränssnittet var extremt obekvämt och mycket annorlunda än den fullständiga versionen.

1C är en klient-server-mjukvara och det betyder att 1C består av två program - klient och server. 1C-serverprogrammet körs på servern. Användaren på sin dator arbetar i 1C-klientprogram, som kort och gott kallas 1C-klienten.

1C har flera typer av klienter, vilket gör att du kan använda programmet på olika datorutrustning, olika operativsystem och geografiskt distribuerade.

En av 1C-klienterna låter dig använda 1C med en vanlig webbläsare på vilket operativsystem som helst (även en Mac). En annan 1C-klient finns på en PDA, till exempel en produktions-PDA i ett lager för inventering, med en streckkodsläsare.

Låt oss titta på vad 1C-kunder är, vad är deras skillnader, hur ser de ut och hur man arbetar med dem?

Tjock klient 1C

Den enklaste och mest välkända 1C-klienten är den tjocka 1C-klienten ("vanlig"). Före version 1C 8.2, förutom den, fanns inga andra alternativ.

1C-konfiguratorn (för närvarande) fungerar bara i den tjocka 1C-klienten. Det rekommenderas också att arbeta med fildatabasen med den tjocka 1C-klienten.

För tillfället antas det att alla 1C-konfigurationer kommer att överföras till den tunna 1C-klienten under det kommande år eller två. Därför är det exakta ödet för den tjocka 1C-klienten i framtiden fortfarande oklart.

Den tjocka 1C-klienten körs på Windows. Det kallas fett eftersom det kräver resurserna på användarens dator. Dessutom kan den tjocka 1C-klienten begära ganska stora mängder data över nätverket.

Ur en programmerares synvinkel är den största skillnaden mellan den tjocka 1C-klienten att den kör de flesta program i det inbyggda 1C-språket på användarens dator. Till exempel vill 1C köra en fråga från databasen:

  • 1C-klienten begär data från 1C-servern
  • Data skickas till 1C-klienten
  • 1C-klienten bearbetar data.

Det tjocka 1C-klientgränssnittet ser ut så här. Som standard är endast användarmenyn öppen. Användaren väljer ett menyalternativ, vilket vanligtvis öppnar ett fönster (någon sorts lista). Därefter arbetar användaren med listan.

Vissa konfigurationer för den tjocka 1C-klienten har ett skrivbord. Så här ser han ut. Först och främst är dessa konfigurationer för redovisning och löner och personal.

Tunn klient 1C

Den tunna 1C-klienten dök upp relativt nyligen. Trade Management-konfigurationen (version 11) har redan släppts för den tunna 1C-klienten. Den tunna 1C-klienten installeras som standard tillsammans med andra 1C-klientalternativ, men den kan installeras separat (endast den).

1C-konfiguratorn fungerar inte i den tunna 1C-klienten. Det kan fungera med en filversion av databasen, men det är bättre att använda klient-serverläge.

Den tunna 1C-klienten körs också på Windows. Det kallas tunt på grund av den korrekta organisationen av programmets klient-serverorganisation. Till skillnad från den 1C tjocka klienten kommer en fråga från databasen att se ut så här:

  • 1C-klienten överför till 1C-servern användarens behov av att begära data från 1C-servern
  • Server 1C begär data från databasen
  • 1C-server bearbetar data
  • Resultatet av databehandlingen skickas till 1C-klienten.

Som du förstår föds ett plus och ett minus omedelbart. Plus - inga krav på resurserna på användarens dator, mindre trafik förväntas. Nackdel – högre krav på serverresurser.

Den sista nackdelen för stora företag elimineras av att 1C-servern kan skalas, det vill säga installera ett system med flera 1C-servrar på olika datorer och de kommer att fungera tillsammans.

1C tunna klientgränssnittet ser ut så här. Som standard öppnas användarens skrivbord. Den är indelad i block efter typ av redovisning. Användaren öppnar ett bokmärke och använder hyperlänkar för att öppna listor.

En ytterligare skillnad mellan en tunn 1C-klient och en tjock är att den inte bara kan fungera via TCP/IP, som den tjocka, utan också via HTTP, som 1C-webbklienten.

Webbklient 1C (webbklient 1C, Linuxklient 1C)

1C-webbklienten låter dig använda 1C via en vanlig webbläsare. Du behöver inte installera något extra för att använda det. Kan användas under alla operativsystem, inklusive till exempel iPad.

Du kan se hur 1C ser ut när du arbetar i 1C-webbklienten just nu. För att göra detta, gå till den officiella demon av Trade Management-konfigurationen (version 11).

För att använda 1C-webbklienten måste du installera en webbserver. Den används uteslutande som en transport och överför förfrågningar till 1C-servern. Logiken för att utföra frågor och bearbeta data i 1C-webbklienten är densamma som i 1C-tunna klienten. För att fungera använder vi automatisk konvertering av det inbyggda 1C-språket till JavaScript.

I 1C-webbklienten kan du inte använda några 1C-konfigurationer - bara de som är skrivna specifikt för att arbeta med den tunna 1C-klienten. I teorin är utvecklingen av konfigurationer för den tunna 1C-klienten och för 1C-webbklienten densamma (gränssnittet och systemets beteende bör också vara detsamma).

Det finns dock rykten om att, åtminstone för tillfället, inte allt är så smidigt och vissa funktioner orsakar fel i 1C-webbklienten, även om de fungerar i den tunna 1C-klienten.

1C webbklientgränssnittet ser ut så här. Som du kan se skiljer den sig lite från den tunna 1C-klienten.

1C-klient för handdatorer (1C-tillägg för fickdatorer)

1C kan även användas på handdatorer (fictdatorer, smartphones). Det finns till och med speciella industriella handdatorer för arbete i ett lager eller i butik, de har vanligtvis en integrerad streckkodsläsare.

För att arbeta med 1C på en handdator kan du använda webbtillägget 1C (se nedan) – det vill säga en liten webbplats som fungerar direkt med 1C. Men specifikt för handdatorer med operativsystemet Windows Mobile 5.0 och högre eller Pocket PC 2003, finns det en 1C-klient för handdatorer.

1C-tillägget för handdatorer fungerar enligt följande:

  • PDA:n begär data från 1C (WiFi, GPRS, bluetooth)
  • PDA:n bearbetar data med hjälp av speciella formulär för PDA:n
  • PDA:n skriver ut data till skrivaren (kommunikation på liknande sätt)
  • PDA:n sparar data i 1C.

1C-klienten för PDA låter dig använda konfiguratorn i en något förkortad form, vilket gör att du kan arbeta med kataloger, dokument, register och deras formulär.

Webtillägg 1C och webbtjänster 1C (Webbtillägg och tjänster 1C)

Antalet sajter som arbetar direkt med 1C eller som kan behöva arbeta direkt med 1C växer. Ett enkelt exempel är en webbutik. Direktkommunikation med 1C kan användas för att ta emot saldon online, rabatter, kundprofiler och spara beställningar.

För att integrera med en webbplats använder de vanligtvis periodiskt utbyte (som i CMS för webbplatser och onlinebutiker 1C Bitrix) eller onlinekommunikation med 1C. För att driva en webbplats online med 1C kan du använda 1C webbtillägg eller 1C webbtjänster.

Webtillägg 1C är en tilläggsprodukt som levereras separat. Det låter dig utveckla webbplatser på ASP .NET-plattformen som fungerar genom en pool av COM-anslutningar från 1C. Att skapa en kö av COM-anslutningar, spara och manipulera dem är redan skrivet i webbtilläggsmotorn för 1C.

1C-webbtjänster är funktionerna hos 1C-plattformen (1C-server). För att använda dem behöver du inte köpa eller installera ytterligare programvara från 1C.

Kräver en webbserver (MS IIS eller Apache) och dess enkla konfiguration (anslutning av ISAPI-tillägget). Därefter kan 1C publicera sina egna webbtjänster. 1C webbtjänster låter dig både begära data från 1C och skriva data till 1C.

Säkerheten är organiserad av det faktum att inga automatiska funktioner tillhandahålls, till skillnad från en COM-anslutning - programmeraren själv föreskriver funktionernas kapacitet, därför, om programmeraren inte gjorde ett hål (en universell post), kommer den inte att existera.

1C-webbklienten är för närvarande fortfarande lite grov och när du arbetar med den kan du stöta på fel som stör och irriterar. Detta betyder inte att det inte går att arbeta med - programmeraren kan ta bort de konfigurationsplatser som orsakar fel.

Naturligtvis är 1C-webbklienten framtiden för 1C-plattformen. Det är oberoende av operativsystem (Windows, Unix, Mac), webbläsare (IE, Chrome, Safari, Firefox, Opera) och kräver inte datorresurser.

En av de trevliga funktionerna med 1C:Enterprise-teknologin är att applikationslösningen, utvecklad med teknik för hanterade formulär, kan lanseras både i en tunn (körbar) klient för Windows, Linux, MacOS X, och som en webbklient för 5 webbläsare - Chrome, Internet Explorer, Firefox, Safari, Edge och allt detta utan att ändra applikationens källkod. Dessutom, externt fungerar och ser applikationen i den tunna klienten och i webbläsaren nästan identisk ut.
Hitta 10 skillnader (2 bilder under snittet):

Tunt klientfönster på Linux:

Samma fönster i webbklienten (i webbläsaren Chrome):

Varför skapade vi en webbklient? För att uttrycka det lite patetiskt, tiden har satt en sådan uppgift för oss. Att arbeta över Internet har länge varit en förutsättning för affärsapplikationer. Först lade vi till möjligheten att arbeta via Internet för vår tunna klient (några av våra konkurrenter slutade förresten där, andra tvärtom övergav den tunna klienten och begränsade sig till att implementera en webbklient). Vi bestämde oss för att ge våra användare möjligheten att välja det klientalternativ som passar dem bäst.

Att lägga till webbaserade funktioner till den tunna klienten var ett stort projekt med en fullständig förändring av klient-server-arkitekturen. Att skapa en webbklient är ett helt nytt projekt som börjar från början.

Formulering av problemet

Så, projektkraven: webbklienten måste göra samma sak som den tunna klienten, nämligen:
  1. Visa användargränssnitt
  2. Kör klientkod skriven på 1C-språk
Användargränssnittet i 1C beskrivs i en visuell redigerare, men deklarativt, utan pixel-för-pixel-arrangemang av element; Cirka tre dussin typer av gränssnittselement används - knappar, inmatningsfält (text, siffror, datum/tid), listor, tabeller, grafer, etc.

Klientkod på 1C-språket kan innehålla serveranrop, arbete med lokala resurser (filer etc.), utskrift och mycket mer.

Både den tunna klienten (när man arbetar via webben) och webbklienten använder samma uppsättning webbtjänster för att kommunicera med 1C-applikationsservern. Klientimplementeringarna är naturligtvis olika - den tunna klienten är skriven i C++, webbklienten är skriven i JavaScript.

Lite historia

Webbklientprojektet startade 2006, med ett team på (i genomsnitt) 5 personer. I vissa skeden av projektet involverades utvecklare för att implementera specifik funktionalitet (kalkylbladsdokument, diagram, etc.); som regel var det samma utvecklare som gjorde den här funktionen i den tunna klienten. De där. utvecklare skrev om komponenter i JavaScript som de tidigare hade skapat i C++.

Redan från början avvisade vi idén om varje automatisk (även partiell) konvertering av C++-tunnklientkod till JavaScript-webbklient på grund av de starka konceptuella skillnaderna mellan de två språken; webbklienten skrevs i JavaScript från grunden.

I de första iterationerna av projektet konverterade webbklienten klientkoden i det inbyggda 1C-språket direkt till JavaScript. Den tunna klienten agerar annorlunda - koden i det inbyggda 1C-språket kompileras till bytekod, och sedan tolkas denna bytekod på klienten. Därefter började webbklienten göra detsamma - för det första gav det en prestandavinst, och för det andra gjorde det det möjligt att förena arkitekturen för de tunna klienterna och webbklienterna.

Den första versionen av 1C:Enterprise-plattformen med webbklientstöd släpptes 2009. Webklienten vid den tiden stödde 2 webbläsare - Internet Explorer och Firefox. De ursprungliga planerna inkluderade stöd för Opera, men på grund av oöverstigliga problem vid den tiden med applikationens stängningshanterare i Opera (det var inte möjligt att spåra med 100% säkerhet att applikationen stängdes, och i det ögonblicket utföra frånkopplingsproceduren från 1C-applikationsservern) från dessa planer måste överges.

Projektets struktur

Totalt har 1C:Enterprise-plattformen 4 projekt skrivna i JavaScript:
  1. WebTools är vanliga bibliotek som används av andra projekt (vi inkluderar även Google Closure Library här).
  2. Formaterad dokumentkontroll
  3. Schemaläggarkontroll (implementerad i JavaScript i både den tunna klienten och webbklienten)
  4. Webbklient
Strukturen för varje projekt liknar strukturen för Java-projekt (eller .NET-projekt - beroende på vad som ligger närmast); Vi har namnutrymmen och varje namnområde finns i en separat mapp. Inuti mappen finns filer och namnområdesklasser. Det finns cirka 1000 filer i webbklientprojektet.

Strukturellt är webbklienten till stor del uppdelad i följande delsystem:

  • Hanterat klientapplikationsgränssnitt
    • Allmänt applikationsgränssnitt (systemmenyer, paneler)
    • Gränssnitt för hanterade formulär, inklusive bland annat ett 30-tal kontroller (knappar, olika typer av inmatningsfält - text, numerisk, datum/tid, etc., tabeller, listor, grafer, etc.)
  • Objektmodell tillgänglig för utvecklare på klienten (över 400 typer totalt: objektmodell för hanterat gränssnitt, inställningar för datalayout, villkorlig stil, etc.)
  • Tolk av det inbyggda 1C-språket
  • Webbläsartillägg (används för funktioner som inte stöds i JavaScript)
    • Jobbar med kryptografi
    • Arbeta med filer
    • Teknik för externa komponenter, vilket gör att de kan användas i både tunna klienter och webbklienter

Utvecklingsfunktioner

Att implementera allt ovan i JavaScript är inte lätt. Kanske är 1C-webbklienten en av de största klientsidans applikationer skrivna i JavaScript - cirka 450 000 rader. Vi använder aktivt ett objektorienterat förhållningssätt i webbklientkoden, vilket förenklar arbetet med ett så stort projekt.

För att minimera storleken på klientkoden använde vi först vår egen obfuscator, och från och med plattformsversion 8.3.6 (oktober 2014) började vi använda Google Closure Compiler. Effekten av användning i siffror – storleken på webbklientramverket efter förvirring:

  • Egen obfuscator – 1556 kb
  • Google Closure Compiler – 1073 kb
Att använda Google Closure Compiler hjälpte oss att förbättra prestandan för webbklienten med 30 % jämfört med vår egen obfuscator. Dessutom har mängden minne som konsumeras av applikationen minskat med 15-25 % (beroende på webbläsare).

Google Closure Compiler fungerar mycket bra med objektorienterad kod, så dess effektivitet för webbklienten är så hög som möjligt. Closure Compiler gör några bra saker för oss:

  • Statisk typkontroll i projektets byggskede (säkerställer att vi täcker koden med JSDoc-kommentarer). Resultatet är statisk typning, mycket nära att skriva i C++ i nivå. Detta hjälper till att fånga upp en ganska stor procentandel av fel i projektsammanställningsstadiet.
  • Minska kodstorleken genom förvirring
  • Ett antal optimeringar av den körda koden, till exempel, såsom:
    • inline funktionsersättningar. Att anropa en funktion i JavaScript är en ganska dyr operation, och inline-ersättningar av ofta använda små metoder påskyndar koden avsevärt.
    • Räknekonstanter vid kompileringstid. Om ett uttryck beror på en konstant, kommer det faktiska värdet av konstanten att ersättas i det
Vi använder WebStorm som vår webbklientutvecklingsmiljö.

För att analysera kod använder vi SonarQube, där vi integrerar statiska kodanalysatorer. Med hjälp av analysatorer övervakar vi försämringen av kvaliteten på JavaScript-källkoden och försöker förhindra det.

Vilka problem löste/löser vi?

Under genomförandet av projektet stötte vi på ett antal intressanta problem som vi var tvungna att lösa.

Utbyta data med servern och mellan fönster

Det finns situationer där förvirring av källkoden kan störa systemets funktion. Kod utanför webbklientens körbara kod, på grund av förvirring, kan ha funktions- och parameternamn som skiljer sig från de som vår körbara kod förväntar sig. Den externa koden för oss är:
  • Kod som kommer från servern i form av datastrukturer
  • Kod för ett annat programfönster
För att undvika förvirring när vi interagerar med servern använder vi taggen @expose:

/** * @constructor * @extends (Base.SrvObject) */ Srv.Core.GenericException = function () ( /** * @typ (sträng) * @expose */ this.descr; /** * @typ (Srv.Core.GenericException) * @expose */ this.inner; /** * @type (sträng) * @expose */ this.clsid /** * @type (boolean) * @expose */ this. kodad)
Och för att undvika förvirring när vi interagerar med andra fönster använder vi så kallade exporterade gränssnitt (gränssnitt där alla metoder exporteras).

/** * Exporterat DropDownWindow-kontrollgränssnitt * * @interface * @struct */ WebUI.IDropDownWindowExp = function()() /** * Flyttar markeringen framåt eller bakåt med 1 * * @param (boolean) isForward * @param ( boolean ) checkOnly * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarker = funktion (isForward, checkOnly)() /** * Flyttar markeringen till början eller slutet * * @param (boolean) isFirst * @param (boolean) checkOnly * @return (boolean) * @expose */ WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly)() /** * @return (boolean) * @expose */ WebUI. IDropDownWindowExp.prototype .selectValue = funktion ()()

Vi använde Virtual DOM innan det blev mainstream)

Liksom alla utvecklare som sysslar med komplexa webbgränssnitt, insåg vi snabbt att DOM är dåligt lämpat för att arbeta med dynamiska användargränssnitt. Nästan omedelbart implementerades en analog av Virtual DOM för att optimera arbetet med användargränssnittet. Under händelsebearbetning lagras alla DOM-ändringar i minnet och endast när alla operationer är slutförda tillämpas de ackumulerade ändringarna på DOM-trädet.

Optimera webbklienten

För att få vår webbklient att fungera snabbare försöker vi använda standardfunktionerna i webbläsaren (CSS, etc.) maximalt. Således renderas formulärets kommandopanel (som finns på nästan varje form av applikationen) uteslutande med webbläsarverktyg, med dynamisk layout baserad på CSS.

Testning

För funktions- och prestandatestning använder vi ett proprietärt verktyg (skrivet i Java och C++) samt en uppsättning tester byggda ovanpå Selenium.

Vårt verktyg är universellt - det låter dig testa nästan alla fönsterprogram, och är därför lämpligt för att testa både en tunn klient och en webbklient. Verktyget registrerar handlingar av användaren som lanserade 1C-applikationslösningen i en skriptfil. Samtidigt spelas bilder av skärmens arbetsområde - standarder - in. Vid övervakning av nya versioner av webbklienten spelas skript utan användarmedverkan. I de fall skärmdumpen inte stämmer överens med referensen i något steg anses testet vara misslyckat, varefter en kvalitetsspecialist gör en utredning för att fastställa om detta är ett fel eller en planerad förändring av systemets beteende. Vid planerat beteende ersätts standarderna automatiskt med nya.

Verktyget mäter också applikationsprestanda med en noggrannhet på upp till 25 millisekunder. I vissa fall slingrar vi delar av skriptet (till exempel genom att upprepa orderinmatningen flera gånger) för att analysera försämringen av exekveringstiden över tid. Resultaten av alla mätningar registreras i en logg för analys.


Vårt testverktyg och applikation under test

Vårt verktyg och Selen kompletterar varandra; till exempel, om någon knapp på en av skärmarna har ändrat sin plats, kanske Selenium inte spårar detta, men vårt verktyg kommer att märka det, eftersom gör en pixel-för-pixel-jämförelse av skärmdumpen med standarden. Verktyget kan också spåra problem med att bearbeta indata från tangentbordet eller musen, eftersom det är exakt vad det återger.

Tester på båda verktygen (vårt och Selenium) kör typiska arbetsscenarier från våra applikationslösningar. Tester startas automatiskt efter den dagliga uppbyggnaden av 1C:Enterprise-plattformen. Om skript är långsammare (jämfört med föregående version) undersöker vi och löser orsaken till nedgången. Vårt kriterium är enkelt - den nya konstruktionen ska inte fungera långsammare än den tidigare.

Utvecklare använder olika verktyg för att undersöka avmattningsincidenter; används främst Dynatrace AJAX Edition producerad av DynaTrace. Loggar över utförandet av den problematiska operationen på föregående och nya byggnader registreras, sedan analyseras loggarna. Samtidigt kan exekveringstiden för enstaka operationer (i millisekunder) inte vara en avgörande faktor - tjänsteprocesser som skräphämtning startas med jämna mellanrum i webbläsaren, de kan överlappa med exekveringstiden för funktioner och förvränga bilden. Mer relevanta parametrar i detta fall skulle vara antalet JavaScript-instruktioner som körs, antalet atomära operationer på DOM, etc. Om antalet instruktioner/operationer i samma skript har ökat i en ny version innebär detta nästan alltid en prestandasänkning som behöver korrigeras.

En av anledningarna till prestandasänkningen kan också vara att Google Closure Compiler av någon anledning inte kunde utföra inline-ersättning av funktionen (till exempel eftersom funktionen är rekursiv eller virtuell). I det här fallet försöker vi korrigera situationen genom att skriva om källkoden.

Webbläsartillägg

Om en applikationslösning behöver funktionalitet som inte är tillgänglig i JavaScript använder vi webbläsartillägg:
  • för att arbeta med filer
  • för att arbeta med kryptografi
  • arbeta med externa komponenter
Våra förlängningar består av två delar. Den första delen är vad som kallas webbläsartillägg (vanligtvis tillägg för Chrome och Firefox skrivna i JavaScript), som interagerar med den andra delen – ett binärt tillägg som implementerar den funktionalitet vi behöver. Det bör nämnas att vi skriver 3 versioner av binära tillägg - för Windows, Linux och MacOS. Det binära tillägget tillhandahålls som en del av 1C:Enterprise-plattformen och finns på 1C-applikationsservern. När den anropas för första gången från en webbklient, laddas den ner till klientdatorn och installeras i webbläsaren.

När de körs i Safari använder våra tillägg NPAPI när de körs i Internet Explorer, de använder ActiveX-teknik. Microsoft Edge stöder ännu inte tillägg, så webbklienten i den fungerar med begränsningar.

Ytterligare utveckling

En av uppgifterna för webbklientutvecklingsteamet är vidareutveckling av funktionalitet. Funktionaliteten hos webbklienten bör vara identisk med funktionaliteten hos den tunna klienten all ny funktionalitet implementeras samtidigt i både den tunna klienten och webbklienten.

Andra uppgifter inkluderar arkitekturutveckling, refactoring, prestanda- och tillförlitlighetsförbättringar. Till exempel är en av riktningarna ytterligare förflyttning mot en asynkron arbetsmodell. En del av funktionaliteten hos webbklienten bygger för närvarande på en synkron modell för interaktion med servern. Den asynkrona modellen blir nu mer relevant i webbläsare (och inte bara i webbläsare), och detta tvingar oss att modifiera webbklienten genom att ersätta synkrona anrop med asynkrona (och omstrukturera koden därefter). Den gradvisa övergången till en asynkron modell förklaras av behovet av att stödja släppta lösningar och deras gradvisa anpassning.

Taggar: Lägg till taggar