Anwendung auf TSD und Kommunikation mit 1C: Enterprise 8.3 über HTTP-Service. Teil 1 (Auswahl einer Austauschmethode. Beschreibung der API)

  1. Die Wahl der Austauschmethode. API-Beschreibung.
  2. API-Implementierung auf der 1C-Seite.
  3. BroadcastReceiver Wir erhalten einen Barcode am Beispiel von ATOL Smart.Lite.
  4. OnKeyUp. Holen Sie sich einen Barcode von einem Scanner mit Tastaturemulation
  5. Menü, Begleitobjekt
  6. Wir realisieren den Datenaustausch und die Speicherung. Wir verwenden Retrofit 2, Room, Coroutines.
  7. Benutzeroberfläche LiveData, PagedList.

Für wen


Die ersten beiden Kapitel sind ein Versuch, die Erfahrung der Integration von 1C in andere Anwendungen und Webdienste zu strukturieren. Ich denke, der Zyklus selbst wird für 1C-Programmierer interessant sein, die versuchen, über die Plattform hinauszugehen und etwas Neues auszuprobieren. Entwickler von Android-Anwendungen werden nichts Neues für sich selbst lernen, aber vielleicht werden sie daran interessiert sein, wie es auf der 1C-Seite aussieht. Ab dem vierten Teil wird versucht, mehrere verstreute Artikel aus dem Internet über die Nutzung von Bibliotheken zu kombinieren und Daten darüber zu aktualisieren. Der Zyklus wurde als Lehrbuch konzipiert, das die Erfahrung bei der Entwicklung einer realen Anwendung beschreibt. Ich selbst bin kein Android-Entwickler. Aber bis zum Ende der Serie hoffe ich, einer zu werden.

2. Die Wahl der Austauschmethode. API-Beschreibung


In der aktuellen Form kann 1C auf tausendfache Weise kontaktiert werden. Betrachten Sie mehrere Optionen und warum ich sie nicht verwendet habe.

  • Native Komponente - Zum größten Teil ist es gut, sie für die Offline-Freigabe zu verwenden. Für Online ist es schlecht angepasst. Es wurde noch schlimmer, als 1C begann, seine Standards für den Austausch mit kommerziellen Geräten umzusetzen. Und auch diese Komponente wird auf der 1C-Seite aufgerufen. Passt nicht zu mir.
  • WEB Services - Mehr für den Austausch zwischen Anwendungen, die verschiedene Teams entwickeln. Schwergewicht, verwenden Sie XML. Persönlich fällt es mir sehr schwer, mich zu entwickeln. Und noch schwieriger in JavaScript, Golang usw. zu integrieren. Ungeeignet.
  • HTTP-Dienste - Fast das Gleiche wie WEB-Dienste, aber wir beschreiben die Logik der Arbeit und tauschen Protokolle vollständig selbst aus. Hier beschränken wir uns nicht nur auf die Erfindung unseres eigenen Fahrrads. Aus diesem Grund wurde dieser spezielle Austauschmechanismus gewählt.

Die Aufgaben, die unsere Anwendung löst. "Alles, was auf der TSD getan werden kann, muss auf der TSD getan werden." Nun, als Standard-Set: Akzeptanz, Inventar, Etiketten, Preisschilder.

Vollständige Liste der Aufgaben
  • Arbeiten mit Waren: Drucken von Etiketten und Preisschildern, Zuweisen eines Barcodes (Barcode), Überprüfen des Barcodes, Entfernen des Barcodes, Anzeigen von Preisen und Mengen in Lagern.
  • Inventar - Tatsächlich Inventar führen.
  • Empfang - Annahme von Waren auf der Rechnung, Drucken von Unstimmigkeiten, Drucken interner Dokumente, Rechnungsstatus.
  • Abholung von Waren, Realisierung (Einzelhandel) - Die Idee ist, dass Verkäufer nicht an der Kasse sind, sondern mit dem Käufer gehen oder Waren auf Anfrage usw. abholen. Es ist nur eine Person am Kassenschalter, ein Bereitschaftsscheck wird von der TSD gesendet. Der Käufer bezahlt nur die Ware.
  • Abholung von Waren, Realisierung (Großhandel) - Wir sammeln Waren auf dem Konto. Wir prüfen, was verfügbar ist. Wir bilden eine Sendung (mit einem Paket der notwendigen Unterlagen). Vergessen Sie nicht, die Möglichkeit des Versands an die Gegenpartei zu prüfen.
  • Warenabholung, Versandvorbereitung - Wir holen Waren auf Anfrage ab, legen sie auf eine Palette, drucken Dokumente: Packliste usw.
  • Umzug - Wir sammeln Waren für den Umzug, wir geben in Lieferung.
  • Warensammlung, eine beliebige Liste - Wird für Neubewertungen, Aktualisierung von Preisschildern, Etiketten und ähnlichen Vorgängen benötigt.


Zurück zur API-Struktur. Der Austausch zwischen TSD und 1C erfolgt im JSON-Format. In der Antwort haben wir nur zwei Objekte {Ergebnis, Nutzlast} : das Ergebnis und die Nutzlast . Als Ergebnis geben wir zwei Felder zurück {code, msg} . Und wir werden immer mit HTTP-Code 200 antworten. So wird es für uns auf der Clientseite einfacher sein, die Antwortstruktur zu analysieren. Alle anderen Antworten werden als Zeichenfolge angezeigt. 1C erlaubt es uns nicht, Antworten außerhalb der Plattform anzupassen.

Warum es einfacher ist, 200 zu geben
Die meisten Bibliotheken für die Arbeit mit Daten (einschließlich Nachrüstung) analysieren das Ergebnis nicht, wenn sie anderen Code als 200 empfangen. Und wir müssen es mit Stiften „analysieren“.

Jetzt erhalten wir das folgende Diagramm. Wenn die Antwort 200 ist, haben unsere Verfahren in 1C gut funktioniert. Wenn eine andere Antwort vorliegt, haben wir unten ein Problem. Hier können wir nicht tief gehen, was schief gelaufen ist, sondern dem Benutzer sofort zeigen, welcher Fehler und seine Beschreibung. Jemand kann sagen, dass Fehler ohne Benutzereingriff verarbeitet werden müssen, aber wir können zwei Situationen haben: 1 - Der Server hat einen Fehler zurückgegeben. 2 - kitschig keine Verbindung. Im ersten Fall wissen wir möglicherweise nicht einmal, dass etwas kaputt ist (Beispiel: Fehler 404: Die Anwendung hat eine nicht vorhandene Methode angefordert. 500: Die Plattform ist mit einer Ausnahme abgestürzt). Im zweiten Fall können wir das Ergebnis zur Analyse nicht auf den Server übertragen. Daher zeigen wir einen Fehler und freuen uns auf weitere Benutzeraktionen.

Die Nutzdaten enthalten verschiedene Objekte. Dies kann eine Warenliste sein, eine Liste von Dokumenten, eine Liste von Aktionen wird dort übertragen. Auf der Anwendungsseite werden wir sie mit Modellen beschreiben und sie sorgfältig in die Datenbank einbinden. Wir werden die Liste der auszuführenden Aktionen starten und die Ergebnisse sorgfältig zur Datenbank hinzufügen.

Der Austauschzyklus mit der TSD wird wie folgt sein:

  1. Die Anwendung auf Befehl sendet eine Anfrage an 1C.
  2. 1C bildet eine Antwort und gibt eine Struktur mit dem Ergebnis und den Daten zurück. In 1C akkumulieren Informationsregister geänderte Daten im Kontext von TSD (Webdienst).
  3. Auf Anfrage der Anwendung wird eine Liste der aufzurufenden Methoden gesendet.

Ein solches Schema wurde gewählt, weil die TSD aus, aus dem Netzwerk usw. ausgeschaltet werden kann. Nichts hindert uns jedoch daran, 1C abzuschließen, sodass Sie beim Ändern von Daten eine andere Anwendung (Webdienst) darüber benachrichtigen müssen. Mit diesem Austausch informieren wir, dass es neue Daten gibt. Die Anwendung fragt, welche Daten vorhanden sind, und die Schleife wird wiederholt. Ein Beispiel für einen Austausch ist im Diagramm dargestellt.



Das ist alles Wenn Sie Fragen, Kommentare, Vorschläge haben, schreiben Sie bitte in die Kommentare.

Source: https://habr.com/ru/post/de473500/


All Articles