Jakie są najważniejsze wymagania dotyczące aplikacji biznesowych? Do najważniejszych zadań należą:
- Łatwość zmiany/dostosowania logiki aplikacji do zmieniających się zadań biznesowych.
- Łatwa integracja z innymi aplikacjami.
Sposób rozwiązania pierwszego zadania w 1C został pokrótce opisany w sekcji „Dostosowywanie i wsparcie”. ; Do tego interesującego tematu powrócimy w kolejnym artykule. Dzisiaj porozmawiamy o drugim zadaniu, integracji.
Zadania integracyjne
Zadania integracyjne mogą być różne. Aby rozwiązać niektóre problemy wystarczy prosta interaktywna wymiana danych – np. przesłanie listy pracowników do banku w celu wydania plastikowych kart płacowych. W przypadku bardziej złożonych zadań może okazać się konieczna w pełni zautomatyzowana wymiana danych, ewentualnie z odniesieniem do logiki biznesowej systemu zewnętrznego. Zdarzają się zadania o charakterze specjalistycznym, jak np. integracja ze sprzętem zewnętrznym (np. sprzętem detalicznym, skanerami mobilnymi itp.) lub z systemami dotychczasowymi lub wysokospecjalistycznymi (np. z systemami rozpoznawania tagów RFID). Niezwykle istotne jest dobranie najodpowiedniejszego mechanizmu integracji do każdego zadania.
Opcje integracji z 1C
Istnieją różne podejścia do wdrażania integracji z aplikacjami 1C, który wybrać zależy od wymagań zadania.
- Oparte na wdrożeniu udostępniane przez platformę, własne wyspecjalizowane API po stronie aplikacji 1C (na przykład zestaw usług internetowych lub HTTP, które będą wywoływać aplikacje innych firm w celu wymiany danych z aplikacją 1C). Zaletą tego podejścia jest odporność API na zmiany w implementacji po stronie aplikacji 1C. Specyfika tego podejścia polega na tym, że konieczna jest zmiana kodu źródłowego standardowego rozwiązania 1C, co może potencjalnie wymagać wysiłku podczas łączenia kodów źródłowych podczas przejścia do nowej wersji konfiguracji. W tym przypadku na ratunek może przyjść nowa progresywna funkcjonalność - . Rozszerzenia to w istocie mechanizm wtyczek, który umożliwia tworzenie dodatków do rozwiązań aplikacyjnych bez zmiany samych rozwiązań aplikacyjnych. Przeniesienie API integracyjnego do rozszerzenia konfiguracyjnego pozwoli uniknąć trudności podczas łączenia konfiguracji przy przejściu na nową wersję standardowego rozwiązania.
- Korzystanie z mechanizmów integracji platformy, które zapewniają zewnętrzny dostęp do modelu obiektowego aplikacji i nie wymagają modyfikacji aplikacji ani tworzenia rozszerzenia. Zaletą tego podejścia jest to, że nie ma potrzeby zmiany aplikacji 1C. Minus - jeśli aplikacja 1C została ulepszona, w zintegrowanej aplikacji mogą być wymagane ulepszenia. Przykładem takiego podejścia jest wykorzystanie do integracji protokołu OData, zaimplementowanego po stronie platformy 1C:Enterprise (więcej o tym poniżej).
- Wykorzystanie gotowych protokołów aplikacyjnych zaimplementowanych w standardowych rozwiązaniach 1C. Wiele standardowych rozwiązań firmy 1C i partnerów wdraża własne protokoły aplikacyjne, skoncentrowane na konkretnych zadaniach, w oparciu o mechanizmy integracyjne udostępniane przez platformę. Korzystając z tych mechanizmów, nie ma potrzeby pisania kodu po stronie aplikacji 1C, ponieważ Korzystamy ze standardowych możliwości rozwiązania aplikacyjnego. Po stronie aplikacji 1C musimy jedynie dokonać pewnych ustawień.
Mechanizmy integracyjne w platformie 1C:Enterprise
Importuj/eksportuj pliki
Załóżmy, że mamy do czynienia z zadaniem dwukierunkowej wymiany danych między aplikacją 1C a dowolną aplikacją. Na przykład musimy zsynchronizować listę produktów (katalog nomenklatury) między aplikacją 1C a dowolną aplikacją.
Aby rozwiązać ten problem, możesz napisać rozszerzenie, które pobierze katalog Nomenklatury do pliku o określonym formacie (tekst, XML, JSON, ...) i będzie w stanie odczytać ten format.
Platforma implementuje mechanizm serializacji obiektów aplikacji w formacie XML zarówno bezpośrednio, poprzez metody kontekstu globalnego WriteXML/ReadXML, jak i z wykorzystaniem obiektu pomocniczego XDTO (XML Data Transfer Objects).
Dowolny obiekt w systemie 1C:Enterprise można serializować do reprezentacji XML i odwrotnie.
Ta funkcja zwróci reprezentację XML obiektu:
Функция Объект_В_XML(Объект)
ЗаписьXML = Новый ЗаписьXML();
ЗаписьXML.УстановитьСтроку();
ЗаписатьXML(ЗаписьXML, Объект);
Возврат ЗаписьXML.Закрыть();
КонецФункции
Tak będzie wyglądać eksport katalogu Nomenklatury do formatu XML przy użyciu XDTO:
&НаСервере
Процедура ЭкспортXMLНаСервере()
НовыйСериализаторXDTO = СериализаторXDTO;
НоваяЗаписьXML = Новый ЗаписьXML();
НоваяЗаписьXML.ОткрытьФайл("C:DataНоменклатура.xml", "UTF-8");
НоваяЗаписьXML.ЗаписатьОбъявлениеXML();
НоваяЗаписьXML.ЗаписатьНачалоЭлемента("СправочникНоменклатура");
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектНоменклатура = Выборка.ПолучитьОбъект();
НовыйСериализаторXDTO.ЗаписатьXML(НоваяЗаписьXML, ОбъектНоменклатура, НазначениеТипаXML.Явное);
КонецЦикла;
НоваяЗаписьXML.ЗаписатьКонецЭлемента();
НоваяЗаписьXML.Закрыть();
КонецПроцедуры
Po prostu modyfikując kod, eksportujemy katalog do formatu JSON. Produkty zostaną zapisane w tablicy; Dla urozmaicenia oto angielska wersja składni:
&AtServer
Procedure ExportJSONOnServer()
NewXDTOSerializer = XDTOSerializer;
NewJSONWriter = New JSONWriter();
NewJSONWriter.OpenFile("C:DataНоменклатура.json", "UTF-8");
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("СправочникНоменклатура");
NewJSONWriter.WriteStartArray();
Selection = Catalogs.Номенклатура.Select();
While Selection.Next() Do
NomenclatureObject = Selection.GetObject();
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("Номенклатура");
NewXDTOSerializer.WriteJSON(NewJSONWriter, NomenclatureObject, XMLTypeAssignment.Implicit);
NewJSONWriter.WriteEndObject();
EndDo;
NewJSONWriter.WriteEndArray();
NewJSONWriter.WriteEndObject();
NewJSONWriter.Close();
EndProcedure
Następnie pozostaje już tylko przekazanie danych konsumentowi końcowemu. Platforma 1C:Enterprise obsługuje główne protokoły internetowe HTTP, FTP, POP3, SMTP, IMAP, w tym ich bezpieczne wersje. Do przesyłania danych można także używać usług HTTP i/lub sieci Web.
HTTP i usługi sieciowe
Aplikacje 1C mogą implementować własne usługi HTTP i sieciowe, a także wywoływać usługi HTTP i sieciowe realizowane przez aplikacje innych firm.
Interfejs REST i protokół OData
Począwszy od wersji 8.3.5 platforma 1C:Enterprise może automatycznie dla całego rozwiązania aplikacyjnego. Dowolny obiekt konfiguracyjny (katalog, dokument, rejestr informacyjny itp.) można udostępnić do odbioru i modyfikacji danych poprzez interfejs REST. Platforma wykorzystuje ten protokół jako protokół dostępu wersja 3.0. Publikowanie usług OData odbywa się z poziomu menu Konfiguratora „Administracja -> Publikowanie na serwerze WWW”, należy zaznaczyć opcję „Publikuj standardowy interfejs OData”. Obsługiwane są formaty Atom/XML i JSON. Po opublikowaniu rozwiązania aplikacji na serwerze WWW, systemy innych firm mogą uzyskać do niego dostęp poprzez interfejs REST za pomocą żądań HTTP. Aby pracować z aplikacją 1C za pośrednictwem protokołu OData, programowanie po stronie 1C nie jest wymagane.
Zatem adres URL taki jak http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура zwróci nam zawartość katalogu Nomenklatury w formacie XML - zbiór elementów wpisu (dla uproszczenia tytuł wiadomości pominięty):
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
<title type="text"/>
<updated>2016-06-06T16:42:17</updated>
<author/>
<summary/>
<link rel="edit" href="Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')" title="edit-link"/>
<content type="application/xml">
<m:properties >
<d:Ref_Key>35d1f6e4-289b-11e6-8ba4-e03f49b16074</d:Ref_Key>
<d:DataVersion>AAAAAgAAAAA=</d:DataVersion>
<d:DeletionMark>false</d:DeletionMark>
<d:Code>000000001</d:Code>
<d:Description>Кондиционер Mitsubishi</d:Description>
<d:Описание>Мощность 2,5 кВт, режимы работы: тепло/холод</d:Описание>
</m:properties>
</content>
</entry>
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
...
Dodając do adresu URL ciąg „?$format=application/json” otrzymujemy zawartość katalogu Nomenklatury w formacie JSON (adres URL formularza http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура?$format=application/json ):
{
"odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_Номенклатура",
"value": [{
"Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAgAAAAA=",
"DeletionMark": false,
"Code": "000000001",
"Description": "Кондиционер Mitsubishi",
"Описание": "Мощность 2,5 кВт, режимы работы: тепло/холод"
},{
"Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAwAAAAA=",
"DeletionMark": false,
"Code": "000000002",
"Description": "Кондиционер Daikin",
"Описание": "Мощность 3 кВт, режимы работы: тепло/холод"
}, …
Zewnętrzne źródła danych
W niektórych przypadkach wymiana danych poprzez może być najlepszym rozwiązaniem. Zewnętrzne źródła danych to obiekt konfiguracyjny aplikacji 1C, który umożliwia interakcję z dowolną bazą danych kompatybilną z ODBC, zarówno w celu odczytu, jak i zapisu. Zewnętrzne źródła danych są dostępne zarówno w systemie Windows, jak i Linux.
Mechanizm wymiany danych
przeznaczony jest zarówno do tworzenia rozproszonych geograficznie systemów opartych na 1C:Enterprise, jak i do organizowania wymiany danych z innymi systemami informatycznymi nie opartymi na 1C:Enterprise.
Mechanizm ten jest aktywnie wykorzystywany we wdrożeniach 1C, a zakres zadań rozwiązywanych za jego pomocą jest bardzo szeroki. Obejmuje to wymianę danych pomiędzy aplikacjami 1C zainstalowanymi w oddziałach organizacji oraz wymianę pomiędzy aplikacją 1C a stroną sklepu internetowego, a także wymianę danych pomiędzy aplikacją serwera 1C a klientem mobilnym (utworzonym przy użyciu platformy mobilnej 1C:Enterprise) oraz wiele więcej.
Jednym z kluczowych pojęć w mechanizmie wymiany danych jest plan wymiany. Plan wymiany to specjalny rodzaj obiektu platformy aplikacji 1C, który określa w szczególności skład danych, które będą uczestniczyć w wymianie (które katalogi, dokumenty, rejestry itp.). Plan wymiany zawiera także informacje o uczestnikach wymiany (tzw. węzłach wymiany).
Drugim elementem mechanizmu wymiany danych jest mechanizm rejestracji zmian. Mechanizm ten automatycznie monitoruje system pod kątem zmian w danych, które muszą zostać przekazane użytkownikom końcowym w ramach planu wymiany. Dzięki temu mechanizmowi platforma śledzi zmiany, jakie zaszły od ostatniej synchronizacji i pozwala zminimalizować ilość danych przesyłanych podczas kolejnej sesji synchronizacji.
Wymiana danych odbywa się za pomocą komunikatów XML o określonej strukturze. Wiadomość zawiera dane, które uległy zmianie od ostatniej synchronizacji z węzłem oraz niektóre informacje serwisowe. Struktura wiadomości obsługuje numerację wiadomości i pozwala na otrzymanie potwierdzenia od węzła odbiorcy, że wiadomości zostały odebrane. Potwierdzenie takie zawarte jest w każdym komunikacie przychodzącym od węzła odbiorczego, w postaci numeru ostatniego odebranego komunikatu. Numerowanie komunikatów pozwala platformie zrozumieć, jakie dane zostały już pomyślnie przesłane do węzła odbiorczego i uniknąć ponownej transmisji poprzez przesyłanie tylko tych danych, które uległy zmianie od czasu, gdy węzeł nadawczy otrzymał ostatni komunikat z potwierdzeniem odbioru danych przez węzeł odbiorczy. Ten schemat działania zapewnia gwarantowaną dostawę nawet w przypadku zawodnych kanałów transmisji i utraty wiadomości.
Komponenty zewnętrzne
W wielu przypadkach rozwiązując problemy integracyjne trzeba stawić czoła specyficznym wymaganiom, na przykład protokołom interakcji, formatom danych, które nie są przewidziane w platformie 1C:Enterprise. Platforma zapewnia taki zakres zadań , który pozwala na dynamiczne tworzenie modułów wtyczek rozszerzających funkcjonalność 1C:Enterprise.
Typowym przykładem zadania o podobnych wymaganiach byłaby integracja rozwiązania aplikacyjnego 1C ze sprzętem detalicznym, począwszy od wag po kasy fiskalne i skanery kodów kreskowych. Komponenty zewnętrzne można podłączyć zarówno po stronie serwera 1C:Enterprise, jak i po stronie klienta (w tym między innymi klienta internetowego, a także 1C: Przedsiębiorstwo). Technologia komponentów zewnętrznych zapewnia dość prosty i zrozumiały interfejs oprogramowania (C++) do interakcji komponentów z platformą 1C:Enterprise, który musi zostać zaimplementowany przez programistę.
Możliwości jakie otwierają się przy zastosowaniu komponentów zewnętrznych są bardzo szerokie. Można zaimplementować interakcję za pomocą określonego protokołu wymiany danych z urządzeniami i systemami zewnętrznymi, wbudować określone algorytmy przetwarzania danych i formaty danych itp.
Przestarzałe mechanizmy integracji
Platforma udostępnia mechanizmy integracyjne, które nie są zalecane do stosowania w nowych rozwiązaniach; pozostawia się je ze względu na kompatybilność wsteczną, a także na wypadek, gdyby druga strona nie mogła pracować z bardziej nowoczesnymi protokołami. Jednym z nich jest praca z plikami w formacie DBF (obsługiwanym w wbudowanym języku za pomocą obiektu XBase).
Kolejnym dotychczasowym mechanizmem integracji jest wykorzystanie technologii COM (dostępnej wyłącznie na platformie Windows). Platforma 1C:Enterprise zapewnia dwie metody integracji dla systemu Windows przy użyciu technologii COM: serwer automatyzacji i połączenie zewnętrzne. Są bardzo podobne, jednak jedną z zasadniczych różnic jest to, że w przypadku serwera Automation uruchamiana jest pełnoprawna aplikacja kliencka 1C:Enterprise 8, a w przypadku połączenia zewnętrznego stosunkowo niewielki procesowy COM serwer zostaje uruchomiony. Oznacza to, że jeśli pracujesz poprzez serwer Automation, możesz korzystać z funkcjonalności aplikacji klienckiej i wykonywać akcje podobne do interaktywnych działań użytkownika. Podczas korzystania z połączenia zewnętrznego można używać tylko funkcji logiki biznesowej i można je wykonywać zarówno po stronie klienta połączenia, gdzie tworzony jest serwer COM w procesie, jak i można wywoływać logikę biznesową na serwerze 1C:Enterprise strona.
Technologii COM można również używać do uzyskiwania dostępu do systemów zewnętrznych z poziomu kodu aplikacji na platformie 1C:Enterprise. W tym przypadku aplikacja 1C działa jako klient COM. Należy jednak pamiętać, że mechanizmy te będą działać tylko wtedy, gdy serwer 1C działa w środowisku Windows.
Mechanizmy integracyjne zaimplementowane w standardowych konfiguracjach
Format danych korporacyjnych
W szeregu konfiguracji 1C (lista poniżej), w oparciu o opisany powyżej mechanizm wymiany danych platformy, realizowany jest gotowy mechanizm wymiany danych z aplikacjami zewnętrznymi, który nie wymaga zmiany kodu źródłowego konfiguracji (przygotowanie do danych wymiana odbywa się w ustawieniach rozwiązań aplikacyjnych):
- „1C:ERP Zarządzanie przedsiębiorstwem 2.0”
- „Kompleksowa automatyzacja 2”
- „Rachunkowość przedsiębiorstwa”, wydanie 3.0
- „Rachunkowość przedsiębiorstwa CORP”, wydanie 3.0
- „Detal”, wydanie 2.0
- „Podstawy zarządzania handlem”, wydanie 11
- Zarządzanie handlem, wydanie 11
- „Zarządzanie wynagrodzeniami i personelem CORP”, wydanie 3
Format używany do wymiany danych to , w oparciu o XML. Format jest zorientowany biznesowo - opisane w nim struktury danych odpowiadają podmiotom gospodarczym (dokumentom i elementom katalogu) prezentowanym w programach 1C, na przykład: akt realizacji, zlecenie odbioru gotówki, kontrahent, pozycja itp.
Może nastąpić wymiana danych między aplikacją 1C a aplikacją strony trzeciej:
- poprzez dedykowany katalog plików
- poprzez katalog FTP
- za pośrednictwem usługi internetowej wdrożonej po stronie aplikacji 1C. Plik danych jest przekazywany jako parametr do metod internetowych
- poprzez e-mail
W przypadku wymiany za pośrednictwem usługi internetowej aplikacja strony trzeciej zainicjuje sesję wymiany danych, wywołując odpowiednie metody sieciowe aplikacji 1C. W pozostałych przypadkach inicjatorem sesji wymiany będzie aplikacja 1C (poprzez umieszczenie pliku danych w odpowiednim katalogu lub przesłanie pliku danych na skonfigurowany adres e-mail).
Również po stronie 1C możesz skonfigurować częstotliwość synchronizacji (dla opcji z wymianą plików przez katalog i e-mail):
- zgodnie z harmonogramem (z określoną częstotliwością)
- ręcznie; użytkownik będzie musiał ręcznie rozpoczynać synchronizację za każdym razem, gdy będzie tego potrzebować
Potwierdzanie wiadomości
Aplikacje 1C prowadzą rejestr wysłanych i odebranych wiadomości synchronizacyjnych i tego samego oczekują od aplikacji innych firm. Dzięki temu można skorzystać z mechanizmu numerowania komunikatów opisanego powyżej w sekcji „Mechanizm wymiany danych”.
Podczas synchronizacji aplikacje 1C przesyłają tylko informacje o zmianach, które zaszły w podmiotach biznesowych od ostatniej synchronizacji (aby zminimalizować ilość przesyłanych informacji). Podczas pierwszej synchronizacji aplikacja 1C prześle wszystkie podmioty gospodarcze (na przykład pozycje księgi referencyjnej pozycji) w formacie EnterpriseData do pliku XML (ponieważ wszystkie są „nowe” dla aplikacji zewnętrznej). Aplikacja strony trzeciej musi przetworzyć informacje z pliku XML otrzymanego od 1C i podczas następnej sesji synchronizacji umieścić w pliku wysłanym do 1C, w specjalnej sekcji XML, informację, że wiadomość od 1C o określonym numerze została pomyślnie wysłana otrzymane. Komunikat odbioru jest sygnałem dla aplikacji 1C, że wszystkie podmioty gospodarcze zostały pomyślnie przetworzone przez aplikację zewnętrzną i nie ma już potrzeby przesyłania informacji o nich. Oprócz paragonu plik XML z aplikacji innej firmy może zawierać również dane do synchronizacji przez aplikację (na przykład dokumenty dotyczące sprzedaży 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. Jedynie niezsynchronizowane zmiany w podmiotach biznesowych (tworzenie nowych, zmiana i usuwanie istniejących) zostaną przesłane do aplikacji zewnętrznej podczas kolejnej sesji synchronizacji.
Podczas przesyłania danych z aplikacji zewnętrznej do aplikacji 1C obraz jest odwrócony. Zewnętrzna aplikacja musi odpowiednio wypełnić sekcję paragonu pliku XML i umieścić ze swojej strony dane biznesowe do synchronizacji w formacie EnterpriseData.
Uproszczona wymiana danych bez uzgadniania
W przypadkach prostej integracji, gdy wystarczy przesłać informacje z aplikacji strony trzeciej do aplikacji 1C, a odwrotne przesyłanie danych z aplikacji 1C do aplikacji strony trzeciej nie jest wymagane (na przykład integracja aplikacji online sklep, który przekazuje informacje o sprzedaży do 1C: Księgowość), istnieje uproszczona opcja pracy za pośrednictwem usługi internetowej (bez potwierdzenia), która nie wymaga ustawień po stronie aplikacji 1C.
Niestandardowe rozwiązania integracyjne
Istnieje standardowe rozwiązanie „1C: Konwersja danych”, które wykorzystuje mechanizmy platformy do konwersji i wymiany danych między standardowymi konfiguracjami 1C, ale może być również wykorzystywane do integracji z aplikacjami innych firm.
Integracja z rozwiązaniami bankowymi
Standard , opracowany przez specjalistów 1C ponad 10 lat temu, faktycznie stał się standardem branżowym w Rosji. Kolejnym krokiem w tym kierunku jest technologia , który umożliwia wysyłanie dokumentów płatniczych do banku i otrzymywanie wyciągów z banku bezpośrednio z programów systemu 1C:Enterprise poprzez naciśnięcie jednego przycisku w programie 1C; nie wymaga instalowania i uruchamiania dodatkowych programów na komputerze klienckim.
Są też .
inny
Warte wspomnienia , standard wymiany informacji handlowych (opracowany wspólnie z Microsoft, Intel, Price.ru i innymi firmami), .
Źródło: www.habr.com