Jakie są najważniejsze wymagania stawiane aplikacjom biznesowym? Do najważniejszych zadań należą:
- Łatwość zmiany/adaptacji logiki działania aplikacji do zmieniających się zadań biznesowych.
- Łatwość integracji z innymi aplikacjami.
sposób rozwiązania pierwszego zadania w 1C został krótko opisany w sekcji „Dostosowanie i wsparcie” ; wrócimy jeszcze do tego interesującego tematu w jednym z przyszłych artykułów. Dziś skupimy się na drugim zadaniu, czyli integracji.
Zadania integracyjne
Zadania integracyjne mogą być różne. Dla jednych wystarczy prosty interaktywny wymiana danych – na przykład, aby przesłać do banku listę pracowników w celu wydania kart płatniczych na wynagrodzenia. W przypadku bardziej złożonych zadań może być potrzebna całkowicie zautomatyzowana wymiana danych, możliwie z odwołaniem do logiki biznesowej zewnętrznego systemu. Są także zadania o charakterze specjalistycznym, takie jak integracja ze sprzętem zewnętrznym (na przykład, sprzętem handlowym, mobilnymi skanerami itp.) lub z systemami dziedziczonymi lub wąsko wyspecjalizowanymi (na przykład z systemami rozpoznawania znaczników RFID). Kluczowe jest, aby dla każdego zadania wybrać najbardziej odpowiedni mechanizm integracji.
Możliwości integracji z 1C
Istnieją różne podejścia do realizacji integracji z aplikacjami 1C, które z nich wybrać – zależy od wymagań zadania.
- Realizacja oparta na , udostępnianych przez platformę, własnym specjalistycznym API po stronie aplikacji 1C (na przykład, zestawem serwisów Web lub HTTP, które będą wywoływać aplikacje zewnętrzne do wymiany danych z aplikacją 1C). Zaletą tego podejścia jest odporność API na zmiany implementacji po stronie aplikacji 1C. Cechą charakterystyczną podejścia jest to, że wymaga zmiany kodu źródłowego standardowego rozwiązania 1C, co może potencjalnie wymagać wysiłku podczas łączenia kodów źródłowych przy przejściu na nową wersję konfiguracji. W tej sytuacji pomocną może okazać się nowa, nowoczesna funkcjonalność — . Rozszerzenia to w zasadzie mechanizm pluginów, który pozwala na tworzenie dodatków dla aplikacji bez zmiany samej aplikacji. Przeniesienie integrowanego API do rozszerzenia konfiguracji pozwoli uniknąć problemów przy łączeniu konfiguracji podczas aktualizacji do nowej wersji standardowego rozwiązania.
- Wykorzystanie mechanizmów integracji platformy, które zapewniają zewnętrzny dostęp do obiektowej struktury aplikacji i nie wymagają modyfikacji aplikacji ani tworzenia rozszerzeń. Plus tego podejścia – nie trzeba zmieniać aplikacji 1C. Minusem jest to, że jeśli aplikacja 1C została zmodyfikowana, mogą być potrzebne dalsze zmiany w zintegrowanej aplikacji. Przykładem tego podejścia jest wykorzystanie protokołu OData do integracji, zrealizowanego po stronie platformy 1C:Предприятие (więcej o tym poniżej).
- Wykorzystanie gotowych protokołów aplikacyjnych, zrealizowanych w standardowych rozwiązaniach 1C. Wiele standardowych rozwiązań od 1C oraz partnerów tworzy własne protokoły aplikacyjne na bazie mechanizmów integracji dostarczanych przez platformę, skierowane na konkretne zadania. Na korzystanie z tych mechanizmów nie wymaga pisania kodu po stronie aplikacji 1C, ponieważ wykorzystujemy standardowe możliwości rozwiązania aplikacyjnego. Po stronie aplikacji 1C wystarczy przeprowadzić pewne ustawienia.
Mechanizmy integracji w platformie 1C:Предприятие
Import/eksport plików
Załóżmy, że mamy do czynienia z zadaniem dwukierunkowej wymiany danych między aplikacją 1C a dowolną aplikacją. Na przykład musimy zsynchronizować listę towarów (rejestr Nomenkatura) między aplikacją 1C a dowolną aplikacją.
Aby rozwiązać taki problem, można napisać rozszerzenie, które eksportuje rejestr Nomenkatura do pliku w określonym formacie (tekstowy, XML, JSON, …) i potrafi odczytywać ten format.
W platformie zrealizowano mechanizm serializacji obiektów aplikacyjnych do formatu XML, zarówno bezpośrednio, poprzez metody globalnego kontekstu ЗаписатьXML/ЧтениеXML, jak i za pomocą pomocniczego obiektu XDTO (XML Data Transfer Objects).
Każdy obiekt w systemie 1C:Предприятие może być serializowany do reprezentacji XML i odwrotnie.
Ta funkcja zwróci reprezentację obiektu w formie XML:
Funkcja Obiekt_W_XML(Obiekt)
ZapiszXML = Nowy ZapiszXML();
ZapiszXML.UstawStronę();
ZapiszXML(ZapiszXML, Obiekt);
Zwróć ZapiszXML.Zamknij();
KoniecFunkcji
tak będzie wyglądać eksport katalogu Nomenklatura do XML przy użyciu XDTO:
&NaSerwerze
Procedura EksportXMLNaSerwerze()
NowySserializerXDTO = SerializatorXDTO;
NowyZapiszXML = Nowy ZapiszXML();
NowyZapiszXML.OtwórzPlik("C:DataNomenklatura.xml", "UTF-8");
NowyZapiszXML.ZapiszOgłoszenieXML();
NowyZapiszXML.ZapiszPoczątekElementu("KatalogNomenklatura");
Wybór = Katalogi.Nomenklatura.Wybierz();
Podczas Wybór.Następny() Cykle
ObiektNomenklatura = Wybór.PobierzObiekt();
NowySserializerXDTO.ZapiszXML(NowyZapiszXML, ObiektNomenklatura, PrzeznaczenieTypuXML.Jawne);
KoniecCykli;
NowyZapiszXML.ZapiszKoniecElementu();
NowyZapiszXML.Zamknij();
KoniecProcedury
Poprzez prostą przeróbkę kodu eksportujemy katalog do JSON. Produkty będą zapisane w tablicy; dla różnorodności podamy anglojęzyczną wersję składni:
&NaSerwerze
Procedura EksportJSONNaSerwerze()
NowySerializerXDTO = SerializerXDTO;
NowyPisarzJSON = Nowy PisarzJSON();
NowyPisarzJSON.OtwórzPlik("C:DataNomenklatura.json", "UTF-8");
NowyPisarzJSON.ZapiszPoczątekObiektu();
NowyPisarzJSON.ZapiszNazwęWłaściwości("KatalogNomenklatura");
NowyPisarzJSON.ZapiszPoczątekTablicy();
Wybór = Katalogi.Nomenklatura.Wybierz();
Podczas Wybór.Następny() Zrób
ObiektNomenklatura = Wybór.PobierzObiekt();
NowyPisarzJSON.ZapiszPoczątekObiektu();
NowyPisarzJSON.ZapiszNazwęWłaściwości("Nomenklatura");
NowySerializerXDTO.ZapiszJSON(NowyPisarzJSON, ObiektNomenklatura, PrzypisanieTypuXML.Implikowane);
NowyPisarzJSON.ZapiszKoniecObiektu();
KoniecZrób;
NowyPisarzJSON.ZapiszKoniecTablicy();
NowyPisarzJSON.ZapiszKoniecObiektu();
NowyPisarzJSON.Zamknij();
KoniecProcedury
Następnie wystarczy tylko przekazać dane końcowemu użytkownikowi. Platforma 1C:Przedsiębiorstwo wspiera główne protokoły internetowe HTTP, FTP, POP3, SMTP, IMAP, w tym ich bezpieczne wersje. Możliwe jest także użycie HTTP i/lub usług Web do przesyłania danych.
HTTP i usługi internetowe
Aplikacje 1C mogą implementować swoje usługi HTTP i internetowe oraz wywoływać usługi HTTP i internetowe, które zostały wdrożone przez zewnętrzne aplikacje.
Interfejs REST i protokół OData
Począwszy od wersji 8.3.5, platforma 1C:Przedsiębiorstwo może automatycznie dla całego rozwiązania aplikacyjnego. Każdy obiekt konfiguracji (katalog, dokument, rejestr informacji itp.) może być udostępniony do pobierania i modyfikacji danych za pośrednictwem interfejsu REST. Jako protokół dostępu platforma korzysta z protokołu wersji 3.0. Publikacja usług OData odbywa się z menu Konfiguratora „Administracja -> Publikacja na serwerze WWW”, pole „Publikuj standardowy interfejs OData” musi być zaznaczone. Obsługiwane są formaty atom/XML i JSON. Po opublikowaniu rozwiązania aplikacyjnego na serwerze WWW, systemy zewnętrzne mogą się do niego odwoływać za pomocą interfejsu REST z wykorzystaniem zapytań HTTP. Do pracy z aplikacją 1C przez protokół OData programowanie po stronie 1C nie jest wymagane.
Tak, URL w postaci http:////odata/standard.odata/Catalog_Nomenklatura zwróci nam zawartość katalogu Nomenklatura w formacie XML — kolekcję elementów entry (nagłówek wiadomości pominięty dla zwięzłości):
http://server/Config/odata/standard.odata/Catalog_Nomenklatura(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')
Dodając do URL ciąg „?$format=application/json”, otrzymamy zawartość katalogu Nomenklatura w formacie JSON (URL w postaci http:////odata/standard.odata/Catalog_Nomenklatura?$format=application/json ):
{
"odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_Nomenklatura",
"value": [{
"Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAgAAAAA=",
"DeletionMark": false,
"Code": "000000001",
"Description": "Klimatyzator Mitsubishi",
"Opis": "Możliwość 2,5 kW, tryby pracy: ciepło/zimno"
},{
"Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAwAAAAA=",
"DeletionMark": false,
"Code": "000000002",
"Description": "Klimatyzator Daikin",
"Opis": "Możliwość 3 kW, tryby pracy: ciepło/zimno"
}, …
Zewnętrzne źródła danych
W niektórych przypadkach wymiana danych przez może stać się optymalnym rozwiązaniem. Zewnętrzne źródła danych to obiekt aplikacyjny konfiguracji 1C, umożliwiający interakcję z każdą bazą danych zgodną z ODBC zarówno w trybie odczytu, jak i zapisu. Zewnętrzne źródła danych są dostępne zarówno w systemie Windows, jak i na systemie Linux.
Mechanizm wymiany danych
jest przeznaczony zarówno do tworzenia systemów rozproszonych opartych na 1C: Przedsiębiorstwo, jak i do organizacji wymiany danych z innymi systemami informacyjnymi, które nie są oparte na 1C: Przedsiębiorstwo.
Ten mechanizm jest aktywnie wykorzystywany w implementacjach 1C, a zakres zadań, które można zrealizować za jego pomocą, jest dość szeroki. Obejmuje wymianę danych między aplikacjami 1C zainstalowanymi w oddziałach organizacji, wymianę danych między aplikacją 1C a stroną internetową sklepu oraz wymianę danych między serwerową aplikacją 1C a mobilnym klientem (stworzoną przy użyciu mobilnej platformy 1C: Przedsiębiorstwo) i wiele więcej.
Jednym z kluczowych pojęć w mechanizmie wymiany danych jest plan wymiany. Plan wymiany to szczególny typ obiektu aplikacyjnego platformy 1C, który definiuje m.in. skład danych, które wezmą udział w wymianie (jakie dokładnie słowniki, dokumenty, rejestry itp.). Plan wymiany zawiera również informacje o uczestnikach wymiany (tzw. węzłach wymiany).
Drugim składnikiem mechanizmu wymiany danych jest mechanizm rejestracji zmian. Ten mechanizm automatycznie śledzi w systemie zmiany danych, które muszą być przekazane końcowym odbiorcom w ramach planu wymiany. Dzięki temu mechanizmowi platforma śledzi zmiany, które miały miejsce od ostatniej synchronizacji, i pozwala zminimalizować objętość danych przekazywanych w ramach kolejnej sesji synchronizacji.
Wymiana danych odbywa się za pomocą wiadomości XML o określonej strukturze. Wiadomość zawiera dane, które uległy zmianie od ostatniej synchronizacji z węzłem, oraz pewne informacje pomocnicze. Struktura wiadomości wspiera numerację wiadomości i umożliwia otrzymywanie potwierdzeń od węzła odbiorczego o odbiorze wiadomości. Takie potwierdzenie znajduje się w każdej wiadomości przychodzącej od węzła odbiorczego w postaci numeru ostatniej przyjętej wiadomości. Numeracja wiadomości pozwala platformie zrozumieć, jakie dane zostały już pomyślnie przekazane do węzła odbiorczego, oraz unikać ponownego przesyłania, przesyłając jedynie dane, które zmieniły się od momentu odbioru przez węzeł nadawczy ostatniej wiadomości z potwierdzeniem o danych odebranych przez węzeł odbiorczy. Taka metoda działania zapewnia gwarantowaną dostawę nawet przy zawodnych kanałach przesyłowych i utracie wiadomości.
Komponenty zewnętrzne
W niektórych przypadkach, w rozwiązaniach integracyjnych, trzeba się zmierzyć ze specyficznymi wymaganiami, takimi jak protokoły interakcji czy formaty danych, z którymi nie przewidziano pracy w platformie 1C:Enterprise. Dla tego typu zadań platforma przewidziała , która pozwala na tworzenie dynamicznie podłączanych modułów, rozszerzających funkcjonalność 1C:Enterprise.
Typowym przykładem zadania z podobnymi wymaganiami może być integracja rozwiązania aplikacyjnego 1C z urządzeniami handlowymi, począwszy od wag, a skończywszy na kasach fiskalnych i skanerach kodów kreskowych. Komponenty zewnętrzne mogą być podłączane zarówno po stronie serwera 1C:Enterprise, jak i na klienckiej części (w tym, także w kliencie internetowym oraz 1C:Enterprise). Technologia komponentów zewnętrznych przewiduje stosunkowo prosty i zrozumiały programowy interfejs (C++) do interakcji komponentów z platformą 1C:Enterprise, który musi zaimplementować programista.
Możliwości, jakie otwierają się przy użyciu komponentów zewnętrznych, są bardzo szerokie. Można zrealizować interakcję zgodnie ze specyficznym protokołem wymiany danych z zewnętrznymi urządzeniami i systemami, wbudować specyficzne algorytmy przetwarzania danych oraz formaty danych itp.
Przestarzałe mechanizmy integracji
W platformie dostępne są mechanizmy integracji, których nie zaleca się używać w nowych rozwiązaniach; pozostały one ze względów zapewnienia wstecznej kompatybilności oraz na wypadek, gdy druga strona nie może pracować z bardziej nowoczesnymi protokołami. Jednym z nich jest praca z plikami w formacie DBF (obsługiwane w wbudowanym języku przy użyciu obiektu XBase).
Innym przestarzałym mechanizmem integracji jest zastosowanie technologii COM (dostępnej tylko na platformie Windows). Platforma 1C:Enterprise oferuje dwa sposoby integracji dla Windows, które wykorzystują technologię COM: serwer Automatyzacji oraz Zewnętrzne połączenie. Są one bardzo podobne, ale jednym z zasadniczych różnic jest to, że w przypadku serwera Automatyzacji uruchamiane jest pełnowartościowe aplikacyjne oprogramowanie klienta 1C:Enterprise 8, podczas gdy w przypadku zewnętrznego połączenia uruchamiany jest stosunkowo mały wewnętrzny serwer COM. Czyli w przypadku pracy przez serwer Automatyzacji można zaangażować funkcjonalność aplikacji klienckiej i wykonywać działania analogiczne do interaktywnych działań użytkownika. Przy użyciu zewnętrznego połączenia można korzystać tylko z funkcji logiki biznesowej, przy czym mogą być one wykonywane zarówno po stronie klienta połączenia, gdzie tworzony jest wewnętrzny serwer COM, jak i wykonywać wywołania logiki biznesowej po stronie serwera 1C:Enterprise.
Technologię COM można także wykorzystać do komunikacji z zewnętrznymi systemami z kodu aplikacji na platformie 1C:Enterprise. W tym przypadku aplikacja 1C działa jako klient COM. Należy jednak przypomnieć, że te mechanizmy będą działać tylko wtedy, gdy serwer 1C działa w środowisku Windows.
Mechanizmy integracji, zrealizowane w standardowych konfiguracjach
Format EnterpriseData
W niektórych konfiguracjach 1C (lista poniżej) na podstawie opisanego wyżej platformowego mechanizmu wymiany danych zrealizowano gotowy mechanizm wymiany danych z zewnętrznymi aplikacjami, który nie wymaga zmiany kodu źródłowego konfiguracji (przygotowanie do wymiany danych odbywa się w ustawieniach rozwiązań aplikacyjnych):
- «1C:ERP Zarządzanie przedsiębiorstwem 2.0»
- «Kompleksowa automatyzacja 2»
- «Księgowość przedsiębiorstwa», edycja 3.0
- «Księgowość przedsiębiorstwa KORP», edycja 3.0
- «Detal», edycja 2.0
- „Zarządzanie sprzedażą podstawowe”, wersja 11
- „Zarządzanie sprzedażą”, wersja 11
- „Płace i zarządzanie personelem KORP”, wersja 3
Do wymiany danych używany jest format , oparty na XML. Format jest ukierunkowany na biznes – opisane w nim struktury danych odpowiadają biznesowym encjom (dokumentom i elementom słowników) przedstawionym w programach 1C, na przykład: akt wykonanych prac, przychodowy dowód kasowy, kontrahent, asortyment itd.
Wymiana danych między aplikacją 1C a zewnętrzną aplikacją może odbywać się:
- przez dedykowany katalog plików
- przez katalog FTP
- przez usługę webową uruchomioną po stronie aplikacji 1C. Plik z danymi przekazywany jest jako parametr metod webowych
- przez e-mail
W przypadku wymiany przez usługę webową, zewnętrzna aplikacja będzie inicjować sesję wymiany danych poprzez wywołanie odpowiednich metod webowych aplikacji 1C. W pozostałych przypadkach inicjatorem sesji wymiany będzie aplikacja 1C (poprzez umieszczenie pliku z danymi w odpowiednim katalogu lub wysłanie pliku z danymi na skonfigurowany adres e-mail).
Również po stronie 1C konfiguruje się, jak często będzie zachodzić synchronizacja (dla opcji wymiany plików przez katalog i e-mail):
- według harmonogramu (z określoną częstotliwością)
- ręcznie; użytkownik będzie musiał ręcznie uruchamiać synchronizację za każdym razem, gdy będzie to potrzebne
Potwierdzanie wiadomości
Aplikacje 1C prowadzą ewidencję wysłanych i odebranych wiadomości synchronizacji i oczekują tego samego od aplikacji zewnętrznych. Umożliwia to wykorzystanie mechanizmu numeracji wiadomości, opisanego powyżej w sekcji „Mechanizm wymiany danych”.
Aplikacje 1C podczas synchronizacji przesyłają jedynie informacje o zmianach, które zaszły w podmiotach biznesowych od czasu ostatniej synchronizacji (aby zminimalizować objętość przesyłanych danych). Przy pierwszej synchronizacji aplikacja 1C wyeksportuje wszystkie podmioty biznesowe (na przykład elementy katalogu towarów) w formacie EnterpriseData do pliku XML (ponieważ wszystkie są "nowe" dla zewnętrznej aplikacji). Zewnętrzna aplikacja powinna przetworzyć informacje z otrzymanego od 1C pliku XML, a przy następnej sesji synchronizacji umieścić w pliku wysyłanym do 1C w specjalnej sekcji XML informację, że wiadomość od 1C o określonym numerze została pomyślnie przyjęta. Wiadomość potwierdzająca jest dla aplikacji 1C sygnałem, że wszystkie podmioty biznesowe zostały pomyślnie przetworzone przez zewnętrzną aplikację i informacje o nich mogą być przesyłane dalej. Oprócz potwierdzenia, plik XML z zewnętrznej aplikacji może także zawierać dane do synchronizacji ze strony aplikacji (na przykład dokumenty realizacji towarów i usług).
Po otrzymaniu wiadomości potwierdzającej aplikacja 1C oznacza wszystkie zmiany przesłane w poprzedniej wiadomości jako pomyślnie zsynchronizowane. Tylko niesynchronizowane zmiany w podmiotach biznesowych (tworzenie nowych podmiotów, zmiany i usunięcia istniejących) będą wysyłane do zewnętrznej aplikacji podczas następnej sesji synchronizacji.
Podczas przekazywania danych od zewnętrznej aplikacji do aplikacji 1C sytuacja zmienia się na przeciwieństwo. Zewnętrzna aplikacja powinna odpowiednio wypełnić sekcję potwierdzenia w pliku XML i umieścić dane biznesowe do synchronizacji z jej strony w formacie EnterpriseData.
Uproszczona wymiana danych bez potwierdzenia
W przypadkach prostej integracji, gdy wystarczy jedynie przesyłać informacje od zewnętrznej aplikacji do aplikacji 1C i nie jest wymagana odwrotna przesyłka danych z aplikacji 1C do zewnętrznej aplikacji (na przykład integracja sklepu internetowego przesyłającego informacje o sprzedaży do "1C: Księgowość"), dostępna jest uproszczona wersja pracy przez web service (bez potwierdzenia), która nie wymaga konfiguracji po stronie aplikacji 1C.
Specjalistyczne rozwiązania integracyjne
Istnieje standardowe rozwiązanie „1C:Konwersja danych”, które wykorzystuje mechanizmy platformy do konwersji i wymiany danych pomiędzy standardowymi konfiguracjami 1C, ale może być również używane do integracji z aplikacjami zewnętrznymi.
Integracja z rozwiązaniami bankowymi
Standard , opracowane przez specjalistów 1C ponad 10 lat temu, stało się faktycznie standardem branżowym w Rosji. Następnym krokiem w tym kierunku jest technologia , która pozwala na wysyłanie dokumentów płatniczych do banku i odbieranie wyciągów bankowych bezpośrednio z programów systemu „1C:Przedsiębiorstwo” za naciśnięciem jednego przycisku w programie „1C”; przy tym nie jest wymagana instalacja i uruchamianie dodatkowych programów na komputerze klienta.
Jest również .
Inne
Warto wspomnieć o , standardzie wymiany informacji handlowej (opracowanym wspólnie z Microsoft, Intel, Price.ru i innymi firmami), .
Źródło: habr.com
