Application Programming Interface
Zintegrowanie programu WMS.net z popularnymi systemami księgowymi, rachunkowymi czy finansowymi staje się łatwe i bezproblemowe dzięki możliwościom modułu API. Dane są automatycznie i natychmiast pobierane przez system WMS, nie wymagając żadnych dodatkowych działań ze strony użytkowników.
Dzięki wykorzystaniu pełnych możliwości API, Twoje działania związane z obsługą towaru staną się nie tylko bardziej efektywne, ale także znacznie przyspieszone. Program WMS.net umożliwia tworzenie dedykowanych procesów wymiany informacji, co pozwala na automatyczne przesyłanie danych do biura rachunkowego czy innych systemów wspierających zarządzanie firmą.
Bez wątpienia, wykorzystanie zaawansowanego modułu API programu WMS.net otwiera nowe perspektywy dla Twojej firmy. Integracja z innymi systemami staje się prostsza niż kiedykolwiek wcześniej, co pozwala na pełne wykorzystanie potencjału technologicznego w zarządzaniu magazynem. Dzięki temu zyskasz znaczącą przewagę konkurencyjną, zapewniając płynne i efektywne działanie Twojego przedsiębiorstwa.
WebAPI REST
W dzisiejszych czasach, wykorzystanie API webowych stało się nieodłączną częścią architektury oprogramowania, a jednym z najpopularniejszych i najczęściej wykorzystywanych stylów architektury jest REST (representational state transfer). REST w prosty i intuicyjny sposób umożliwia komunikację między różnymi aplikacjami poprzez wykorzystanie standardowych protokołów internetowych.
Główną zaletą REST jest jego prostota i skalowalność. Komunikacja odbywa się poprzez wywołanie usługi interfejsu za pomocą URI (Uniform Resource Identifier) wraz z odpowiednimi parametrami. Dzięki temu, interakcja z API jest łatwa do zrozumienia i implementacji, co pozwala na szybkie rozwijanie i integrowanie różnych systemów.
Wynik działania usługi REST jest zazwyczaj zakodowany w formacie JSON (JavaScript Object Notation) lub XML (eXtensible Markup Language), co pozwala na łatwe przekazywanie danych w strukturalny sposób. JSON jest coraz bardziej popularnym formatem ze względu na jego czytelność i lekkość, co przekłada się na szybszy czas przetwarzania i mniejsze obciążenie sieci.
REST jako styl architektury jest również niezwykle skalowalny, co oznacza, że może obsłużyć duże ilości żądań i użytkowników bez utraty wydajności. Jest to szczególnie istotne w przypadku aplikacji, które potrzebują szybkiego i niezawodnego dostępu do danych.
Wydajność, prostota i skalowalność to tylko niektóre z zalet REST, które sprawiają, że jest on preferowanym stylem architektury dla API webowych. Dzięki niemu możliwa jest sprawniejsza i bardziej efektywna komunikacja między aplikacjami, co przyczynia się do wydajniejszego funkcjonowania systemów informatycznych i usprawnia działanie wielu przedsiębiorstw.
Dokumentacja Swagger YAML lub JSON
Integracja API, szczególnie przy wykorzystaniu preferowanej architektury REST, odgrywa kluczową rolę w rozwijaniu nowoczesnych aplikacji internetowych i mobilnych. Dzięki interfejsowi programowania aplikacji (API) możliwe jest efektywne komunikowanie się między różnymi systemami i aplikacjami, umożliwiając wymianę informacji w szybki i elastyczny sposób.
REST (Representational State Transfer) to popularna architektura oprogramowania, która określa zasady i ograniczenia projektowania API. Jego prostota i elastyczność czynią go preferowanym wyborem dla tworzenia interfejsów programowania. REST opiera się na wykorzystaniu standardowych protokołów internetowych, takich jak HTTP, co pozwala na łatwe korzystanie z API bez potrzeby specjalnych narzędzi czy dodatkowych zależności.
Dokumentacja API odgrywa kluczową rolę w procesie rozwoju aplikacji. Swagger, narzędzie do tworzenia dokumentacji API w formacie YAML, jest jednym z najpopularniejszych rozwiązań. Swagger ułatwia tworzenie i zarządzanie dokumentacją API, zgodną z wymaganiami OpenAPI (OAI). Dzięki temu programiści mają łatwy dostęp do informacji na temat dostępnych punktów końcowych API, sposobu korzystania z nich oraz przekazywania parametrów.
Wykorzystanie dokumentacji w formacie YAML oraz możliwość edycji w czasie rzeczywistym za pomocą Swagger to znaczący atut dla zespołów programistycznych. Pozwala to na bieżące dostosowywanie dokumentacji do zmieniających się wymagań projektowych, co przyczynia się do sprawnego rozwoju aplikacji.
Integracja API z wykorzystaniem preferowanego REST i dokumentacja w formacie YAML z edycją w Swagger stanowią kluczowe elementy w rozwijaniu nowoczesnych aplikacji. Dzięki nim programiści mogą sprawnie wymieniać się informacjami między różnymi systemami i aplikacjami, co przekłada się na wydajność, skalowalność i lepsze doświadczenia użytkowników.
WebAPI WMS
Ten fragment kodu to Swagger Specification w wersji 2.0, czyli format dokumentacji dla API. Zawiera on informacje dotyczące API, takie jak opis, wersja, nazwa, host i ścieżka bazowa.
W sekcji „tags” znajdują się kategorie, które mogą być użyte do grupowania ścieżek, a w „paths” znajdują się konkretne ścieżki dostępne w API. W tym przykładzie jest tylko jedna ścieżka „/ApiService.asmx/Execute”, która obsługuje żądania typu POST.
W sekcji „parameters” znajduje się jeden parametr „body”, który jest obiektem typu „ApiExecuteRequest” i jest przekazywany w żądaniu POST. W sekcji „responses” opisane są odpowiedzi serwera dla każdego możliwego przypadku, takie jak „200” dla udanego wykonania żądania, „401” dla nieprawidłowych danych uwierzytelniających i „400” dla nieprawidłowych danych żądania.
Swagger jest bardzo przydatnym narzędziem do dokumentowania API i pomaga programistom w łatwym zrozumieniu, testowaniu i korzystaniu z API.
Dokumentacja REST API opisuje zbiór dostępnych punktów końcowych (endpoints) oraz możliwości, jakie oferuje API StudioSystem. Poniżej przedstawiony jest opis poszczególnych punktów końcowych oraz ich funkcjonalności:
/ApiService.asmx/Execute
Metoda: POST
Opis: Uniwersalna metoda API. Użyj pól „actionUid” i „actionData” odpowiednio. Pierwsze pole to unikalny identyfikator operacji (guid), a drugie to dopasowany obiekt dla tej operacji (jeden z obiektów ApiExecuteRequest*). Metoda zwraca jeden z obiektów ApiExecuteResponse*.
Metoda ta przyjmuje jako parametr „actionUid”, który jest identyfikatorem polecenia SQL z tabeli „_code_sql”. W ramach tego polecenia SQL może być wywołana procedura, która otrzymuje dane w formie JSON przekazane jako „actionData”. Procedura może następnie wykonać dowolną logikę, korzystając z przesłanych danych, i zwrócić wynik w postaci JSON, który będzie zwracany jako odpowiedź z API.
Oto kroki, które można podjąć, aby skorzystać z tej dedykowanej metody API:
- Sprawdź wersję bazy danych. Upewnij się, że baza ma ustawiony parametr „compatibility level” na wartość 130 lub wyższą.
- Przygotuj dane do wykonania operacji. Przygotuj dane, które zostaną przekazane do API jako „actionData”. Może to być dowolny obiekt JSON, który zostanie przetworzony przez procedurę.
- Wykonaj dedykowaną metodę API. Wywołaj dedykowaną metodę API, przekazując jako parametr „actionUid” identyfikator polecenia SQL z tabeli „_code_sql”, a jako „actionData” dane do przetworzenia przez procedurę.
- Wykonaj logikę w procedurze. W procedurze, którą wywoła polecenie SQL, odbierz dane przesłane jako „actionData” i wykonaj na nich odpowiednią logikę.
- Zwróć wynik z procedury. Procedura powinna zwrócić wynik w formie obiektu JSON, który zostanie zwrócony przez API jako odpowiedź.
- Obsłuż odpowiedź z API. Otrzymasz odpowiedź z API zawierającą wynik z procedury w postaci pliku JSON. Możesz ten wynik przetworzyć i użyć go w dalszej części aplikacji.
Ważne jest również upewnienie się, że connection string do bazy danych, który będzie wykorzystywany w kodzie SQL, jest prawidłowy i umożliwia połączenie z bazą danych.
Parametry:
„body” (w ciele zapytania): Obiekt ApiExecuteRequest (typ danych zdefiniowany w definicjach).
Odpowiedzi:
„200”: Kod API został wykonany z błędem lub bez błędu. Zwraca tablicę obiektów ApiExecuteResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/GetDocumentsByAwizo
Metoda: POST
Opis: Pobiera dokumenty na podstawie numeru awizo.
Parametry:
„body” (w ciele zapytania): Obiekt AuthData (typ danych zdefiniowany w definicjach) – dane uwierzytelniające.
„nrawizo” (w zapytaniu): Numer awizo (wymagany).
„pageSize” (w zapytaniu): Rozmiar strony (opcjonalny).
„pageNumber” (w zapytaniu): Numer strony (opcjonalny).
Odpowiedzi:
„200”: Sukces. Zwraca tablicę obiektów DPMAG_DocumentResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/GetDocumentsByCustomer
Metoda: POST
Opis: Pobiera dokumenty na podstawie identyfikatora klienta.
Parametry:
„body” (w ciele zapytania): Obiekt AuthData (typ danych zdefiniowany w definicjach) – dane uwierzytelniające.
„nridodn” (w zapytaniu): Identyfikator klienta (wymagany).
„ean” (w zapytaniu): Kod EAN klienta (opcjonalny).
„dateFrom” (w zapytaniu): Data od (opcjonalna).
„dateTo” (w zapytaniu): Data do (opcjonalna).
„pageSize” (w zapytaniu): Rozmiar strony (opcjonalny).
„pageNumber” (w zapytaniu): Numer strony (opcjonalny).
Odpowiedzi:
„200”: Sukces. Zwraca tablicę obiektów DPMAG_DocumentResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/AddOrder
Metoda: POST
Opis: Dodaje nowe zamówienie.
Parametry:
„body” (w ciele zapytania): Obiekt DPZLE_AddOrderRequest (typ danych zdefiniowany w definicjach).
Odpowiedzi:
„200”: Sukces. Zwraca obiekt DPZLE_AddOrderResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/GetOrder
Metoda: POST
Opis: Pobiera zamówienie na podstawie numeru zamówienia lub identyfikatora zamówienia.
Parametry:
„body” (w ciele zapytania): Obiekt DPZLE_GetOrderRequest (typ danych zdefiniowany w definicjach).
Odpowiedzi:
„200”: Sukces. Zwraca obiekt DPZLE_GetOrderResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/AddAssortment
Metoda: POST
Opis: Dodaje nowy asortyment.
Parametry:
„body” (w ciele zapytania): Obiekt KNASO_AddAssortmentRequest (typ danych zdefiniowany w definicjach).
Odpowiedzi:
„200”: Sukces. Zwraca obiekt KNASO_AddAssortmentResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/GetAssortment
Metoda: POST
Opis: Pobiera asortyment na podstawie identyfikatora asortymentu.
Parametry:
„body” (w ciele zapytania): Obiekt AuthData (typ danych zdefiniowany w definicjach) – dane uwierzytelniające.
„id” (w zapytaniu): Identyfikator asortymentu (wymagany).
„warehouse” (w zapytaniu): Magazyn (wymagany).
„department” (w zapytaniu): Dział (wymagany).
Odpowiedzi:
„200”: Sukces. Zwraca obiekt KNASO_AssortmentData (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/GetStock
Metoda: POST
Opis: Pobiera stan asortymentu na podstawie magazynu i działu.
Parametry:
„body” (w ciele zapytania): Obiekt AuthData (typ danych zdefiniowany w definicjach) – dane uwierzytelniające.
„warehouse” (w zapytaniu): Magazyn (wymagany).
„department” (w zapytaniu): Dział (wymagany).
„date” (w zapytaniu): Data (opcjonalna).
„pageSize” (w zapytaniu): Rozmiar strony (opcjonalny).
„pageNumber” (w zapytaniu): Numer strony (opcjonalny).
Odpowiedzi:
„200”: Sukces. Zwraca obiekt KNASO_StockDataResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/GetStockDetails
Metoda: POST
Opis: Pobiera szczegóły stanu asortymentu na podstawie magazynu i działu.
Parametry:
„body” (w ciele zapytania): Obiekt AuthData (typ danych zdefiniowany w definicjach) – dane uwierzytelniające.
„warehouse” (w zapytaniu): Magazyn (wymagany).
„department” (w zapytaniu): Dział (wymagany).
„date” (w zapytaniu): Data (opcjonalna).
„pageSize” (w zapytaniu): Rozmiar strony (opcjonalny).
„pageNumber” (w zapytaniu): Numer strony (opcjonalny).
Odpowiedzi:
„200”: Sukces. Zwraca obiekt KNASO_StockDataDetailsResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
/dpmag.asmx/AddContractor
Metoda: POST
Opis: Dodaje nowego kontrahenta.
Parametry:
„body” (w ciele zapytania): Obiekt KNCRM_AddContractorRequest (typ danych zdefiniowany w definicjach).
Odpowiedzi:
„200”: Sukces. Zwraca obiekt KNCRM_AddContractorResponse (typ danych zdefiniowany w definicjach).
„401”: Nieprawidłowe dane uwierzytelniające. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
„400”: Nieprawidłowe dane żądania. Zwraca obiekt ErrorResponse (typ danych zdefiniowany w definicjach).
