OData стандартты интерфейсі 1С:Предприятие платформасында 8.3.5 нұсқасында-ақ пайда болды — бұл 2015 жылғы релиз. Содан бері кез келген конфигурация 1С жағында бір жол код жазбай-ақ анықтамалықтарды, құжаттар мен регистрлерді OData 3.0 нұсқасының хаттамасы бойынша автоматты түрде бере алады. Деректер JSON немесе XML форматында келеді, сұраныстар $filter, $orderby және $select параметрлері арқылы тікелей мекенжай жолында құрылады. Соған қарамастан, он жылдан кейін де біз сайтпен, аналитикамен немесе сыртқы сервистермен алмасу CSV-ге қолмен түсірілімдерге және құрылымның кез келген өзгерісінен бұзылатын түнгі тапсырмаларға сүйенетін компанияларды жиі көреміз. Платформаның қосымша пысықтаусыз-ақ беретін мүмкіндігі мен онымен іс жүзінде қалай жұмыс істейтіні арасындағы алшақтық әлі де орасан зор.
West Star Ltd тәжірибесінде интеграциялық міндеттердің едәуір бөлігі дәл осыған саяды: конфигурацияның өзін пысықтамай-ақ, Python-дағы сыртқы кодқа 1С деректеріне қауіпсіз әрі болжамды қолжетімділік беру. Бұл мақаланың тезисі қарапайым. 1С-тегі OData — экзотика да, уақытша шешім де емес, оның үстіне есептілікті, маркетплейстермен синхрондауды, чат-боттар мен веб-сервистерді құруға болатын толыққанды REST-интерфейс. Төменде бұл интерфейсті қалай көтеру керектігін, Python-нан деректерді қалай оқып, жазуға болатынын және тәсілдің нақты шекаралары қай жерде екенін қадам-қадаммен талдаймыз.
НЕЛІКТЕН ТҮСІРІЛІМДЕР ЕМЕС, ДӘЛ ODATA
OData-ның басты құндылығы — оның өз бетінше жасалған формат емес, стандарт болуында. Кез келген тіл, кез келген BI-жүйе, кез келген HTTP-клиент бірдей ережелерді түсінеді: нысандар тізімін қалай сұрау керек, жолдарды қалай сүзу керек, метадеректерді қалай алу керек. Файл құрылымы туралы келісудің, кодтауларды талдаудың және бөлгіштерді қадағалаудың қажеті жоқ. /odata/standard.odata/$metadata мекенжайына GET түріндегі сұраныс барлық қолжетімді нысандардың, олардың өрістері мен типтерінің толық сипаттамасын қайтарады — бұл 1С пен сыртқы әлем арасындағы өзін-өзі құжаттайтын келісімшарт.
Екінші артықшылығы — нақты уақыт режимінде жұмыс істеу. Қолмен түсірілім әрдайым базаның кешегі күйін көрсетеді, ал OData деректерді сұраныс сәтіндегі күйінде береді. Қоймадағы қалдықтар, тапсырыстардың мәртебелері мен өзара есеп айырысулар үшін бұл аса маңызды. Үшінші сәт — сервер жағында сүзгілеу. Бүкіл номенклатураны түсіріп алып, оны Python-да кесудің орнына, біз 1С-тен дәл қажетті жолдарды ғана сұраймыз және трафикті де, уақытты да үнемдейміз.
СТАНДАРТТЫ ИНТЕРФЕЙСТІ ҚАЛАЙ ҚОСУ КЕРЕК
Интерфейс өздігінен жұмыс істемейді — оны веб-серверде жариялау керек. Ақпараттық базаны Apache немесе IIS арқылы жариялағанда, жариялау баптауларында OData стандартты интерфейсінің қолжетімділігі туралы жалауша қойылады, ал платформа бүкіл конфигурация үшін REST-нүктені өзі жасайды. Осыдан кейін база http://сервер/база_атауы/odata/standard.odata/ түріндегі мекенжай бойынша жауап береді.
Әрі қарай — құқықтар. Сыртқы код атынан жүгінетін пайдаланушыға RemoteAccessOData рөлі қажет, әйтпесе платформа қолжетімділік қатесін қайтарады. Біз интеграция үшін толық құқықты әкімші атынан қосылмай, ең аз қажетті құқықтар жиынтығы бар жеке қызметтік пайдаланушы жасауға кеңес береміз. Бұл әрі қауіпсізірек, әрі тірі қызметкерлерге әсер етпей, қолжетімділікті кез келген сәтте қайтарып алуға мүмкіндік береді. OData арқылы көрінетін нысандардың құрамы да конфигураторда бапталады — сыртқа тек қажетті анықтамалықтар мен құжаттарды ашып, қалғанын жабық қалдыруға болады.
PYTHON-НАН БІРІНШІ СҰРАНЫС
Стандартты интерфейстегі аутентификация — кәдімгі HTTP Basic. Python-да requests кітапханасымен бәрі бірнеше жолға сыяды:
import requests
base = "http://server/base/odata/standard.odata"
auth = ("odata_user", "құпиясөз")
resp = requests.get(
base + "/Catalog_Номенклатура",
params={"$format": "json", "$top": 10},
auth=auth,
)
data = resp.json()
for item in data["value"]:
print(item["Description"], item["Code"])
Мұнда нысандардың атауларына назар аударған жөн. Анықтамалықтарға Catalog_ және анықтамалық атауы, құжаттарға — Document_ және атауы, мәліметтер регистрлеріне — InformationRegister_ және атауы, жинақтау регистрлеріне — AccumulationRegister_ және атауы түрінде жүгінеді. json мәні бар $format параметрі XML орнына JSON сұрайды, $top іріктемені шектейді. Жауап әрдайым value массиві бар объект түрінде келеді — оны талдау кезінде ескеру керек.
СҮЗГІЛЕУ, СҰРЫПТАУ ЖӘНЕ ӨРІСТЕРДІ ТАҢДАУ
OData-ның бүкіл күші сұраныс параметрлерінде ашылады. $filter параметрі іріктеу шартын 1С жағына ауыстырады. Мысалы, жоюға белгіленбеген позицияларды ғана таңдау:
params = {
"$format": "json",
"$filter": "DeletionMark eq false",
"$orderby": "Description asc",
"$select": "Ref_Key,Code,Description",
}
$orderby параметрі сұрыптауды береді, $select қайтарылатын өрістер жиынын шектейді — бұл үлкен анықтамалықтарда жауапты айтарлықтай жеделдетеді. Сүзгілерде eq, ne, gt, lt салыстыру операторлары, and және or логикалық операторлары, сондай-ақ жолдарға арналған startswith және substringof сияқты функциялар жұмыс істейді. Сілтемелік өрістер guid пен нысан типін көрсететін cast конструкциясы арқылы салыстырылады — бұл синтаксистің ең түсініксіз бөлігі, жаңадан бастаушылардың барлығы дерлік осыған сүрінеді. Құрылымды талдау үшін біз әрдайым $metadata сұранысынан бастаймыз: ол өрістердің нақты атауларын көрсетеді, ал олар пайдаланушы 1С интерфейсінде көретін атаулармен әрдайым сәйкес келе бермейді.
ДЕРЕКТЕРДІ 1С-КЕ КЕРІ ЖАЗУ
1С-тегі OData тек оқу үшін ғана жұмыс істемейді. Анықтамалықтың жаңа элементін немесе құжатты JSON форматындағы денесі бар POST арқылы жасауға, барын Ref_Key кілті бойынша PATCH арқылы өзгертуге, құжатты тиісті нысанның арнайы Post функциясын шақыру арқылы өткізуге болады. Контрагент жасаудың қарапайым мысалы:
new_item = {"Description": "Ромашка ЖШС", "Code": "00-001234"}
resp = requests.post(
base + "/Catalog_Контрагенты?$format=json",
json=new_item,
auth=auth,
)
Жазуға біз оқуға қарағанда сақтықпен қараймыз. Конфигурацияның бизнес-логикасын айналып өтіп, құжаттарды тікелей жасау регистрлер бойынша дұрыс емес қозғалыстарға оңай әкеледі, сондықтан күрделі операциялар үшін біз құжатты OData арқылы тікелей жазбай, 1С жағында жазылған, барлық қажетті тексеру орындалатын HTTP-сервисті шақыруды жөн көреміз. OData оқу үшін және қарапайым жазық объектілерді жазу үшін тамаша келеді, бірақ есептің тұтастығы үшін жауапкершілікті жоймайды.
МҰНЫ DJANGO-ҒА ҚАЛАЙ КІРІКТІРУ КЕРЕК
Django-дағы веб-жобада біз әдетте requests шақыруларын view-функцияларға (views) шашыратпаймыз, мекенжайды, аутентификацияны және жауапты талдауды инкапсуляциялайтын жұқа клиенттік қабат — жеке модуль жасаймыз. View-функциялар мен фондық тапсырмалар хаттаманың егжей-тегжейін білмей, соған жүгінеді. Ауыр іріктемелерді Celery фондық тапсырмалары арқылы кэшке немесе жобаның өз дерекқор кестелеріне саламыз, сонда әр пайдаланушы сұранысы 1С-ті тікелей мазаламайды. Мұндай тәсіл бірден екі нәрсе береді: сайт беттері 1С базасының дәл қазір қолжетімді болу-болмауына тәуелді болмайды, ал оған түсетін жүктеме болжамды күйде қалады. Құпияларды — қызметтік пайдаланушының мекенжайын, логині мен құпиясөзін — кодқа емес, орта айнымалыларына шығарамыз және OData-ға желілік қолжетімділікті ол бүкіл интернетке емес, тек біздің қосымшаға көрінетіндей етіп жабамыз.
ШЕКТЕУЛЕР МЕН ӘЛСІЗ ТҰСТАР
1С-тегі OData — жұмыс құралы, бірақ оның шекараларын бірден білген дұрыс.
— Үлкен көлемдердегі өнімділік. Стандартты интерфейс бір сұраныста жүз мыңдаған жолдан тұратын іріктемелерді ұнатпайды. $top және $skip арқылы беттік навигация болмаса, ауыр сұраныстар 1С серверіне жүктеме түсіріп, таймауттарға тіреледі.
— Хаттама нұсқасы. Платформа OData-ны жаңарақ 4.0 емес, 3.0 нұсқасында береді. 4.0 нұсқасына арналған заманауи клиенттер мен кітапханалардың бір бөлігі онымен толық жұмыс істемейді немесе қолмен қосымша баптауды талап етеді.
— Сүзгілердің осал синтаксисі. guid бар cast арқылы сілтемелер бойынша салыстыру, URL-дегі кириллицаны кодтау, регистрге тәуелді өріс атаулары — мұның бәрі байқалуы қиын қателердің көзі. $metadata сұранысынсыз жұмыс істейтін сүзгіні бірінші реттен құрастыру мүмкін емес дерлік.
— Өріс атаулары интерфейспен сәйкес келмейді. Бухгалтер Контрагент деп көретін нәрсе OData-да басқаша аталып, техникалық постфиксі болуы мүмкін. Бұл әзірлеуден емес, есеп жағынан келгендерді үнемі шатастырады.
— Бизнес-логикаға кепілдік берілмейді. Құжаттарды OData арқылы тікелей жазу конфигурацияның тексерулерін айналып өтеді. Бухгалтерлік өткізбелерге және регистр қозғалыстарына әсер ететіннің бәрі үшін стандартты интерфейс арқылы емес, 1С HTTP-сервистері арқылы жүрген қауіпсізірек.
— Әдепкі қауіпсіздік әлсіз. HTTPS-сіз Basic-аутентификация құпиясөзді ашық дерлік түрде беруді білдіреді. Арнаны шифрлау мен желілік шектеулер болмаса, сыртқа ашылған OData тез арада осал тесікке айналады.
ІС ЖҮЗІНДЕ НЕ ІСТЕУ КЕРЕК
Әзірлеуші-маманға кішіден бастаған жөн: базаны тестілік контурда OData қосулы күйде жариялап, $metadata сұратып, номенклатура анықтамалығында алғашқы жұмыс істейтін сүзгіні құрастыру. Бұл хаттама алдындағы қорқыныштың басым бөлігін бір кеште-ақ сейілтеді. Әрі қарай — қолжетімділікті жеке клиенттік модульге шығарып, әр view-функциядан 1С-ке тікелей жүгінбеу.
Команда басшысына ережелерді бекіту маңызды: ең аз құқықтары бар жеке қызметтік пайдаланушы, тек қорғалған арна арқылы қолжетімділік, OData арқылы оқу, ал күрделі жазу — HTTP-сервистер арқылы. Бұл үш шешім әзірлеу басталмай тұрып-ақ тәуекелдердің көпшілігін жабады.
Бизнес иесіне ең бастысын түсіну жеткілікті: 1С-те әлдеқашан жатқан деректерді есепті қымбат қайта құрусыз және қолмен түсірілімдерсіз сайтқа, аналитикаға және чат-боттарға нақты уақыт режимінде беруге болады. Бұл жеке ірі жоба емес, баптау мен бірнеше күндік жұмыстың мәселесі. Егер қазір алмасу файлдарға түсірілімдерге сүйенсе, OData-ға көшу қолмен жіберілетін қателер санының азаюымен-ақ әрдайым дерлік өзін ақтайды.
ЖИІ ҚОЙЫЛАТЫН СҰРАҚТАР
OData-ны қосу үшін 1С конфигурациясын пысықтау керек пе?
Жоқ. Стандартты интерфейсті платформа автоматты түрде жасайды. Базаны веб-серверде OData жалаушасы қосулы күйде жариялап, пайдаланушыға қашықтан қол жеткізу рөлін беру жеткілікті. 1С жағындағы код HTTP-сервистер арқылы күрделірек бизнес-логика қажет болғанда ғана керек.
Деректердің қай форматын қолданған дұрыс — JSON ба, әлде XML ме?
Python және веб-сервистермен интеграция үшін JSON ыңғайлырақ: ол оңайырақ талданады және ықшамырақ. json мәні бар $format параметрін немесе application/json мәні бар Accept тақырыбын қосу жеткілікті. XML тарихи түрде Atom-мен жұмыс істейтін жүйелер үшін қалады.
OData арқылы деректерді тек оқып қана қоймай, жазуға да бола ма?
Иә, POST арқылы жасау, PATCH арқылы өзгерту және жою қолдау табады. Бірақ есепке әсер ететін құжаттар үшін біз бизнес-логиканы толық тексеретін 1С HTTP-сервистері арқылы жазуды, ал OData-ны ең алдымен оқу және қарапайым объектілер үшін пайдалануды ұсынамыз.
Мұны сыртқа ашу қаншалықты қауіпсіз?
Өздігінен — қауіпсіз емес. Қорғалған арна, ең аз құқықтары бар жеке пайдаланушы және желі бойынша қолжетімділікті шектеу міндетті. Осы шарттар сақталса, тәуекел кез келген басқа ішкі API-мен салыстырмалы.