X5:llä on 43 jakelukeskusta ja 4 029 omaa kuorma-autoa, mikä varmistaa häiriöttömän tuotteiden toimituksen 15 752 myymälään. Tässä artikkelissa jaan kokemukseni interaktiivisen järjestelmän luomisesta varastotapahtumien seurantaan alusta alkaen. Tiedoista on hyötyä sellaisten kauppayritysten logistiikoilla, joilla on useita kymmeniä jakelukeskuksia, jotka hallinnoivat laajaa tuotevalikoimaa.
Valvonta- ja liiketoimintaprosessien hallintajärjestelmien rakentaminen alkaa pääsääntöisesti viestien ja tapausten käsittelystä. Samalla jätetään huomiotta tärkeä teknologinen seikka, joka liittyy mahdollisuuteen automatisoida itse bisnestapahtumien esiintyminen ja tallentaa tapahtumat. Useimmissa liiketoimintajärjestelmissä, kuten WMS, TMS jne., on sisäänrakennetut työkalut omien prosessiensa valvontaan. Mutta jos kyseessä on eri valmistajien järjestelmiä tai valvontatoimintoja ei ole riittävästi kehitetty, joudut tilaamaan kalliita muutoksia tai houkuttelemaan erikoistuneita konsultteja lisäasetuksiin.
Tarkastellaanpa lähestymistapaa, jossa tarvitsemme vain pienen osan lähteiden (taulukoiden) tunnistamiseen liittyvästä konsultaatiosta saadaksemme indikaattoreita järjestelmästä.
Varastojemme erityispiirteenä on, että samassa logistiikkakompleksissa toimii useita varastonhallintajärjestelmiä (WMS Exceed). Varastot on jaettu tavaroiden varastointiluokkien (kuiva, alkoholi, pakaste jne.) mukaan, ei vain loogisesti. Yhden logistiikkakompleksin sisällä on useita erillisiä varastorakennuksia, joista jokaista hallinnoi oma WMS-järjestelmä.
Yleiskuvan muodostamiseksi varastossa tapahtuvista prosesseista johtajat analysoivat kunkin WMS:n raportointia useita kertoja päivässä, käsittelevät varastooperaattoreiden (vastaanottajat, keräilijät, pinoajat) viestejä ja tiivistävät todelliset toiminnalliset indikaattorit pohdittavaksi opastetaululle.
Säästääksemme esimiesten aikaa päätimme kehittää edullisen järjestelmän varastotapahtumien operatiiviseen valvontaan. Uuden järjestelmän tulee sen lisäksi, että se näyttää varastoprosessien operatiivisen suorituskyvyn "kuumia" indikaattoreita, auttaa esimiehiä tapausten kirjaamisessa ja tehtävien toteutumisen seurannassa, jotta voidaan poistaa syitä, jotka vaikuttavat annettuihin indikaattoreihin. Yrityksen IT-arkkitehtuurin yleistarkastuksen jälkeen totesimme, että tarvittavan järjestelmän yksittäiset osat ovat jo olemassa tavalla tai toisella maisemissamme ja niitä varten on sekä asetusten tarkastus että tarvittavat tukipalvelut. Jäljelle jää vain koko konsepti yhdeksi arkkitehtoniseksi ratkaisuksi saattaminen ja kehittämisen laajuuden arvioiminen.
Uuden järjestelmän rakentamiseen tarvittavan työn määrän arvioinnin jälkeen projekti päätettiin jakaa useaan vaiheeseen:
- Mittareiden kokoelma varastoprosesseihin, indikaattorien ja poikkeamien visualisointi ja valvonta
- Prosessistandardien automatisointi ja hakemusten rekisteröinti yrityspalvelupalveluun poikkeamien varalta
- Ennakoiva seuranta kuormitusennusteella ja suositusten luominen esimiehille.
Ensimmäisessä vaiheessa järjestelmän on kerättävä valmiit siivut toimintatiedoista kaikilta kompleksin WMS:iltä. Lukeminen tapahtuu lähes reaaliajassa (alle 5 minuutin välein). Temppu on, että tiedot on hankittava useiden kymmenien varastojen DBMS:stä, kun järjestelmä otetaan käyttöön koko verkkoon. Vastaanotetut toimintatiedot käsitellään järjestelmäytimen logiikan avulla poikkeamien laskemiseksi suunnitelluista indikaattoreista ja tilastojen laskemiseksi. Tällä tavalla käsitellyt tiedot on esitettävä johtajan tabletilla tai varaston tietotaululla ymmärrettävinä kaavioina ja kaavioina.
Valittaessa sopivaa järjestelmää ensimmäisen vaiheen pilottitoteutukseen valitsimme Zabbixin. Tätä järjestelmää käytetään jo varastojärjestelmien IT-suorituskyvyn seurantaan. Lisäämällä erillisen asennuksen varastotoiminnan liikemittausten keräämiseen saat kokonaiskuvan varaston tilasta.
Järjestelmän yleinen arkkitehtuuri osoittautui kuvan mukaiseksi.
Jokainen WMS-ilmentymä on määritelty valvontajärjestelmän isäntänä. Tietokeskusverkon keskuspalvelin kerää mittareita suorittamalla komentosarjan valmiilla SQL-kyselyillä. Jos sinun on valvottava järjestelmää, joka ei suosittele suoraa pääsyä tietokantaan (esimerkiksi SAP EWM), voit käyttää komentosarjakutsuja dokumentoituihin API-toimintoihin saadaksesi indikaattoreita tai kirjoittaa yksinkertaisen ohjelman python/vbascriptissä.
Varastoverkkoon otetaan käyttöön Zabbix-välityspalvelinesiintymä jakaakseen kuorman pääpalvelimelta. Välityspalvelimen kautta työskentely kaikkien paikallisten WMS-instanssien kanssa varmistetaan. Seuraavan kerran, kun Zabbix-palvelin pyytää parametreja, isännässä suoritetaan komentosarja Zabbix-välityspalvelimella, joka pyytää mittareita WMS-tietokannasta.
Grafanan näyttäminen näyttää kaavioita ja varastoindikaattoreita Zabbixin keskuspalvelimella. Valmiiden varastotoimintojen infografioiden näyttämisen lisäksi Grafanaa käytetään indikaattoreiden poikkeamien seurantaan ja automaattisten hälytysten lähettämiseen varaston palvelujärjestelmään liiketoimintatapahtumien käsittelyä varten.
Esimerkkinä tarkastellaan kuormanhallinnan toteutusta varaston vastaanottoalueella. Seuraavat valittiin tärkeimmiksi prosessin suorituskyvyn indikaattoreiksi tällä varaston alueella:
- ajoneuvojen lukumäärä vastaanottoalueella ottaen huomioon tilat (suunniteltu, saapunut, asiakirjat, purkaminen, lähtö;
- sijoitus- ja täydennysalueiden työmäärä (varastointiolosuhteiden mukaan).
Asetukset
Järjestelmän pääkomponenttien (SQLcl, Zabbix, Grafana) asennus ja konfigurointi on kuvattu useissa lähteissä, eikä niitä toisteta tässä. SQLcl:n käyttö SQLplusin sijaan johtuu siitä, että SQLcl (Java-kielellä kirjoitettu Oracle DBMS:n komentoriviliittymä) ei vaadi Oracle Client -ohjelmiston lisäasennusta ja toimii heti.
Kuvaan tärkeimmät kohdat, joihin tulisi kiinnittää huomiota käytettäessä Zabbixia varaston liiketoimintaprosessin indikaattoreiden seurantaan, ja yksi mahdollisista tavoista toteuttaa niitä. Tämä ei myöskään ole tietoturvasta. Yhteyksien turvallisuus ja esitettyjen menetelmien käyttö vaatii lisäselvitystä pilottiratkaisun tuottavaan käyttöön siirtämisessä.
Pääasia on, että tällaista järjestelmää toteutettaessa voidaan tehdä ilman ohjelmointia järjestelmän antamilla asetuksilla.
Zabbix-valvontajärjestelmä tarjoaa useita vaihtoehtoja mittareiden keräämiseen valvotusta järjestelmästä. Tämä voidaan tehdä joko suoraan kyselyllä valvotuista isännistä tai edistyneemmällä menetelmällä lähettää tietoja palvelimelle isännän zabbix_senderin kautta, mukaan lukien menetelmät matalan tason etsintäparametrien määrittämiseksi. Ongelmamme ratkaisemiseksi keskuspalvelimen suorittama isäntien suora kysely on varsin sopiva, koska Tämän avulla voit saada täyden hallinnan mittareiden hankintajärjestykseen ja varmistaa, että käytät yhtä asetus-/skriptijoukkoa ilman, että sinun tarvitsee jakaa niitä jokaiselle valvottavalle isännälle.
Käytämme WMS-laskentataulukkoa hyväksynnän hallintaan "testikohteina" virheenkorjauksessa ja järjestelmän asennuksessa:
- Ajoneuvot vastaanotossa, kaikki saapuneet: Kaikki ajoneuvot, joiden tilat ovat ajalta "- 72 tuntia nykyisestä ajasta" - SQL-kyselytunniste: hanki autoja.
- Kaikkien ajoneuvojen tilojen historia: Kaikkien ajoneuvojen tilat, jotka saapuvat 72 tunnin sisällä - SQL-kyselytunniste: autotHistoria.
- Aikataulutetut ajoneuvot hyväksyttäviksi: Kaikkien ajoneuvojen tilat, joiden saapuminen on "Scheduled"-tilassa, aikaväli "- 24 tuntia" ja "+24 tuntia" nykyisestä ajasta - SQL-kyselytunniste: autoja.
Joten kun olemme päättäneet joukosta varaston suorituskykymittareita, valmistelemme SQL-kyselyitä WMS-tietokantaa varten. Kyselyjen suorittamiseen on suositeltavaa käyttää ei päätietokantaa, vaan sen "kuumaa" kopiota - valmiustilaa.
Yhdistämme valmiustilaan Oracle DBMS:ään tietojen vastaanottamiseksi. IP-osoite testitietokantaan yhdistämistä varten 192.168.1.106. Tallennamme yhteysparametrit Zabbix-palvelimelle SQLcl-työkansion TNSNames.ORA-kansioon:
# cat /opt/sqlcl/bin/TNSNames.ORA
WH1_1=
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.106)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = WH1_1)
)
)Tämä antaa meille mahdollisuuden suorittaa SQL-kyselyitä jokaiselle isännälle EZconnectin kautta määrittämällä vain kirjautumistunnuksen/salasanan ja tietokannan nimen:
# sql znew/Zabmon1@WH1_1Tallennamme valmistetut SQL-kyselyt Zabbix-palvelimen työkansioon:
/etc/zabbix/sqlja salli pääsy palvelimemme zabbix-käyttäjälle:
# chown zabbix:zabbix -R /etc/zabbix/sqlPyyntöä sisältävät tiedostot saavat Zabbix-palvelimelta pääsyä varten yksilöllisen tunnisteen-nimen. Jokainen tietokantakysely SQLcl:n kautta palauttaa meille useita parametreja. Ottaen huomioon Zabbixin erityispiirteet, sillä se voi käsitellä vain yhden mittarin pyyntöä kohden, käytämme lisäkomentosarjat kyselyn tulosten jäsentämiseen yksittäisiksi mittareiksi.
Valmistetaan pääskripti, kutsutaan sitä nimellä wh_Metrics.sh, kutsumaan SQL-kysely tietokantaan, tallentamaan tulokset ja palauttamaan tekninen mittari tietojen haun onnistumisen indikaattoreineen:
#!/bin/sh
## настройка окружения</i>
export ORACLE_HOME=/usr/lib/oracle/11.2/client64
export PATH=$PATH:$ORACLE_HOME/bin
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/usr/lib64:/usr/lib:$ORACLE_HOME/bin
export TNS_ADMIN=$ORACLE_HOME/network/admin
export JAVA_HOME=/
alias sql="opt/sqlcl/bin/sql"
## задаём путь к файлу с sql-запросом и параметризованное имя файла
scriptLocation=/etc/zabbix/sql
sqlFile=$scriptLocation/sqlScript_"$2".sql
## задаём путь к файлу для хранения результатов
resultFile=/etc/zabbix/sql/mon_"$1"_main.log
## настраиваем строку подключения к БД
username="$3"
password="$4"
tnsname="$1"
## запрашиваем результат из БД
var=$(sql -s $username/$password@$tnsname < $sqlFile)
## форматируем результат запроса и записываем в файл
echo $var | cut -f5-18 -d " " > $resultFile
## проверяем наличие ошибок
if grep -q ora "$resultFile"; then
echo null > $resultFile
echo 0
else
echo 1
fiAsetamme valmiin tiedoston komentosarjan kanssa ulkoisten komentosarjojen tallentamiseen tarkoitettuun kansioon Zabbix-välityspalvelimen asetusten mukaisesti (oletuksena - /usr/local/share/zabbix/externalscripts).
Sen tietokannan tunniste, josta komentosarja saa tulokset, välitetään komentosarjaparametrina. Tietokannan tunnuksen on vastattava TNSNames.ORA-tiedoston asetusriviä.
SQL-kyselyn tulos tallennetaan tiedostomuotoon mon_base_id_main.log jossa perustunnus = Tietokannan tunniste vastaanotettu komentosarjaparametrina. Tulostiedoston jako tietokantatunnisteiden mukaan tarjotaan, jos palvelimelta lähetetään pyyntöjä useaan tietokantaan samanaikaisesti. Kysely palauttaa lajitellun kaksiulotteisen arvojen joukon.
Seuraava komentosarja, kutsutaan sitä nimellä getMetrica.sh, tarvitaan määritetyn mittarin saamiseksi tiedostosta pyynnön tuloksella:
#!/bin/sh
## определяем имя файла с результатом запроса
resultFile=/etc/zabbix/sql/mon_”$1”_main.log
## разбираем массив значений результата средствами скрипта:
## при работе со статусами, запрос возвращает нам двумерный массив (RSLT) в виде
## {статус1 значение1 статус2 значение2…} разделённых пробелами (значение IFS)
## параметром запроса передаём код статуса и скрипт вернёт значение
IFS=’ ‘
str=$(cat $resultFile)
status_id=null
read –ra RSLT <<< “$str”
for i in “${RSLT[@]}”; do
if [[ “$status_id” == null ]]; then
status_id=”$I"
elif [[ “$status_id” == “$2” ]]; then
echo “$i”
break
else
status_id=null
fi
doneNyt olemme valmiita konfiguroimaan Zabbixin ja aloittamaan varaston vastaanottoprosessien indikaattoreiden seurannan.
Zabbix-agentti asennetaan ja konfiguroidaan jokaiseen tietokantasolmuun.
Pääpalvelimella määritämme kaikki palvelimet Zabbix-välityspalvelimella. Asetuksia varten siirry seuraavaan polkuun:
Hallinta → Välityspalvelin → Luo välityspalvelin
Määrittelemme valvotut isännät:
Asetukset → Isännät → Luo isäntä
Isäntänimen on vastattava agentin määritystiedostossa määritettyä isäntänimeä.
Määritämme solmun ryhmän sekä tietokannan kanssa solmun IP-osoitteen tai DNS-nimen.
Luomme mittareita ja määritämme niiden ominaisuudet:
Asetukset → Solmut → "solmun nimi" → Tietokohteet> Luo tietokohde
1) Luo päämittaus kaikkien parametrien kyselyä varten tietokannasta
Asetamme tietoelementin nimen, ilmoitamme tyypin "Ulkoinen vahvistus". "Key"-kentässä määritämme komentosarjan, jolle välitämme parametreiksi Oracle-tietokannan nimen, sql-kyselyn nimen, kirjautumistunnuksen ja salasanan tietokantaan yhdistämistä varten. Aseta kyselyn päivitysväliksi 5 minuuttia (300 sekuntia).
2) Luo loput tiedot kullekin ajoneuvon tilalle. Näiden mittareiden arvot luodaan päämittarin tarkistuksen tuloksen perusteella.
Asetamme tietoelementin nimen, ilmoitamme tyypin "Ulkoinen vahvistus". "Key"-kentässä määritämme skriptin, jolle välitämme parametreina Oracle-tietokannan nimen ja tilakoodin, jonka arvoa haluamme seurata. Asetamme kyselyn päivitysväliksi 10 sekuntia päämittaria pidemmäksi (310 sekuntia), jotta tulokset ehtivät kirjoittaa tiedostoon.
Jotta mittaukset saadaan oikein, on tärkeää, että tarkastukset aktivoidaan. Välttääksemme ristiriitoja tietojen vastaanottamisessa, aktivoimme ensin päämittarin GetCarsByStatus kutsumalla komentosarjaa - wh_Metrics.sh.
Asetukset → Solmut → 'solmun nimi' → Tietoelementit → Alasuodatin “Ulkoiset tarkistukset”. Merkitse tarvittava valintamerkki ja napsauta "Aktivoi".
Seuraavaksi aktivoimme loput tiedot yhdellä toiminnolla valitsemalla ne kaikki yhdessä:
Nyt Zabbix on aloittanut varastoliiketoiminnan mittareiden keräämisen.
Seuraavissa artikkeleissa tarkastellaan lähemmin Grafanan yhdistämistä ja varastotoimintojen tietopaneelien luomista eri käyttäjäryhmille. Grafanaa käytetään myös varastotoimintojen poikkeamien seurantaan ja poikkeamien rajoista ja tiheydestä riippuen rekisteröidä tapahtumia varastonhallinnan palvelukeskusjärjestelmään API:n kautta tai yksinkertaisesti lähettää ilmoituksia esimiehelle sähköpostitse.
Lähde: will.com