टीएसडी पर आवेदन और 1 सी के साथ संचार: एंटरप्राइज़ 8.3 HTTP-Service के माध्यम से। भाग 1 (एक विनिमय विधि चुनना) एपीआई का विवरण

1. विनिमय विधि का चुनाव। एपीआई विवरण।
2. 1 सी ओर एपीआई कार्यान्वयन।
3. BroadcastReceiver। हमें ATOL Smart.Lite के उदाहरण पर बारकोड प्राप्त होता है।
4. Onkeyup। कीबोर्ड इम्यूलेशन के साथ स्कैनर से बारकोड प्राप्त करें
5. मेनू, साथी वस्तु
6. हमें डेटा एक्सचेंज और स्टोरेज का एहसास होता है। हम Retrofit 2, Room, Coroutines का उपयोग करते हैं।
7. उपयोगकर्ता इंटरफ़ेस LiveData, PagedList।

किसके लिए

पहले दो अध्याय अन्य अनुप्रयोगों और वेब सेवाओं के साथ 1 सी को एकीकृत करने के अनुभव को संरचना करने का एक प्रयास है। मुझे लगता है कि यह चक्र 1C प्रोग्रामर के लिए दिलचस्प होगा, जो मंच से परे जाकर कुछ नया करने की कोशिश कर रहे हैं। एंड्रॉइड एप्लिकेशन डेवलपर्स खुद के लिए कुछ भी नया नहीं सीखेंगे, लेकिन शायद वे इस बात में दिलचस्पी लेंगे कि यह 1 सी तरफ कैसा दिखता है। चौथे भाग के साथ शुरू, पुस्तकालयों के उपयोग पर इंटरनेट से कई बिखरे लेखों को संयोजित करने का प्रयास होगा, साथ ही उन पर डेटा अपडेट भी किया जाएगा। चक्र की कल्पना एक पाठ्यपुस्तक के रूप में की गई थी, जो एक वास्तविक अनुप्रयोग को विकसित करने में अनुभव का वर्णन करती है। मैं खुद एक Android डेवलपर नहीं हूं। लेकिन श्रृंखला के अंत तक मुझे एक बनने की उम्मीद है।

2. विनिमय विधि का चुनाव। एपीआई विवरण

अपने वर्तमान रूप में, 1C को एक हजार और एक तरीके से संपर्क किया जा सकता है। कई विकल्पों पर विचार करें, और मैंने उनका उपयोग क्यों नहीं किया।

• मूल घटक - अधिकांश भाग के लिए, इसे ऑफ़लाइन साझा करने के लिए उपयोग करना अच्छा है। ऑनलाइन के लिए, यह खराब रूप से अनुकूलित है। यह तब और भी बदतर हो गया जब 1 सी ने वाणिज्यिक उपकरणों के साथ विनिमय के लिए अपने मानकों को लागू करना शुरू किया। और यह भी घटक 1C की तरफ कहा जाता है। मुझे शोभा नहीं देता।
• वेब सर्विसेज - अधिक अनुप्रयोगों के बीच आदान-प्रदान के लिए डिज़ाइन किया गया है जो विभिन्न टीमों को विकसित करता है। हेवीवेट, XML का उपयोग करें। व्यक्तिगत रूप से, मुझे विकसित करना बहुत कठिन है। और जावास्क्रिप्ट, गोलांग, आदि में एकीकृत करने के लिए भी कठिन है। उपयुक्त नहीं है।
• HTTP सेवाएँ - लगभग WEB सेवाओं के समान ही हैं, लेकिन हम पूरी तरह से कार्य और विनिमय प्रोटोकॉल के तर्क का वर्णन करते हैं। यहां हम अपनी साइकिल के आविष्कार तक सीमित नहीं हैं। इस कारण से, इस विशेष विनिमय तंत्र को चुना गया था।

हमारे एप्लिकेशन हल करता है कि कार्यों। "TSD पर किया जा सकता है कि सब कुछ TSD पर किया जाना चाहिए।" खैर, एक मानक सेट के रूप में: स्वीकृति, सूची, लेबल, मूल्य टैग।


वापस एपीआई संरचना में। TSD और 1C के बीच एक्सचेंज JSON फॉर्मेट में होगा। उत्तर में हमारे पास क्रमशः केवल दो ऑब्जेक्ट {परिणाम, पेलोड} होंगे, परिणाम और पेलोड । नतीजतन, हम दो फ़ील्ड {कोड, संदेश} वापस कर देंगे। और हम हमेशा HTTP कोड 200 के साथ जवाब देंगे। इसलिए हमारे लिए क्लाइंट की ओर से प्रतिक्रिया संरचना को पार्स करना आसान होगा। अन्य सभी उत्तर एक स्ट्रिंग के रूप में आएंगे। 1C हमें प्लेटफॉर्म के बाहर उत्तर को अनुकूलित करने की अनुमति नहीं देता है।


अब हम निम्नलिखित आरेख प्राप्त करते हैं। यदि उत्तर 200 है, तो 1 सी में हमारी प्रक्रियाओं ने ठीक काम किया। यदि एक अलग उत्तर है, तो हमें नीचे एक समस्या है। यहां हम गहराई से नहीं जा सकते, क्या गलत हुआ, लेकिन तुरंत उपयोगकर्ता को दिखाते हैं कि क्या त्रुटि है, और इसका विवरण। कोई कह सकता है कि त्रुटियों को उपयोगकर्ता के हस्तक्षेप के बिना संसाधित करने की आवश्यकता है, लेकिन हमारे पास दो स्थितियां हो सकती हैं: 1 - सर्वर ने एक त्रुटि लौटा दी। 2 - कॉर्न नो कनेक्शन। पहले मामले में, हम यह भी नहीं जान सकते हैं कि कुछ टूट गया है (उदाहरण के लिए, त्रुटि 404: एप्लिकेशन ने एक अस्तित्व-विहीन विधि का अनुरोध किया। 500: एक अपवाद के साथ प्लेटफॉर्म दुर्घटनाग्रस्त हो गया)। दूसरे में, हम सर्वर के विश्लेषण के लिए परिणाम को स्थानांतरित नहीं कर सकते। इसलिए, हम एक त्रुटि दिखाते हैं, और आगे के उपयोगकर्ता कार्यों के लिए तत्पर हैं।

पेलोड में अलग-अलग ऑब्जेक्ट होंगे। यह माल की एक सूची हो सकती है, दस्तावेजों की एक सूची हो सकती है, कार्यों की एक सूची वहां प्रेषित की जाएगी। आवेदन पक्ष पर, हम उन्हें मॉडल के साथ वर्णन करेंगे और ध्यान से उन्हें डेटाबेस में गुना करेंगे। हम निष्पादन के लिए कार्रवाइयों की सूची लॉन्च करेंगे, और डेटाबेस में परिणामों को सावधानीपूर्वक जोड़ेंगे।

TSD के साथ विनिमय चक्र निम्नानुसार होगा:

1. कमांड पर आवेदन 1 सी के लिए एक अनुरोध भेजता है।
2. 1C एक प्रतिक्रिया बनाता है और परिणाम और डेटा के साथ एक संरचना देता है। 1 सी में, सूचना रजिस्टर टीएसडी (वेब ​​सेवा) के संदर्भ में परिवर्तित डेटा जमा करते हैं।
3. आवेदन से अनुरोध करने पर, बुलाए जाने वाले तरीकों की एक सूची भेजी जाती है।

ऐसी योजना इसलिए चुनी गई क्योंकि TSD को बंद किया जा सकता है, नेटवर्क बंद किया जा सकता है, आदि। लेकिन कुछ भी हमें 1 सी को अंतिम रूप देने से रोकता है ताकि डेटा बदलते समय, इसके बारे में किसी अन्य एप्लिकेशन (वेब ​​सेवा) को सूचित करें। इस विनिमय के साथ, हम सूचित करते हैं कि नया डेटा है। एप्लिकेशन पूछता है कि क्या डेटा है, और लूप दोहराता है। विनिमय का एक उदाहरण आरेख में प्रस्तुत किया गया है।



वह सब है। यदि आपके पास प्रश्न, टिप्पणियाँ, सुझाव हैं, तो कृपया टिप्पणियों में लिखें।