Rib schimb

Utilizarea mecanismului tipic RIB SCP.

Pentru client, principalul dezavantaj al acestei metode este că în bazele de date de pe site-uri există TOATE (aproape) informații ale bazei de date centrale. De asemenea, trebuie instalată platforma 1C.







Pro: ușor de implementat RIB, abilitatea de a crea o structură RIB de copaci, suport pentru actualizarea mecanismului RIB în cadrul unei actualizări UPP tipice.

Utilizarea propriilor reguli de schimb în mecanismul standard RIB PPP.

Pentru clientul de dezavantaje speciale ale acestei metode, nu văd.

Pro: ca și în prima metodă + baza de date nu conține toate datele centrului, ci doar cele necesare pe site.

Dacă luăm regulile de schimb dezvoltate pentru Inter, pentru standard, atunci o ușoară îmbunătățire din partea noastră va dura o zi. Dacă încercăm să facem aceste reguli universale într-o anumită formă, atunci văd o revizuire pentru câteva săptămâni.

Sugestia mea este de a dezvolta un schimb standard pentru procesarea resturilor pe baza Inter. Astfel, va fi un truc in stilul 1C - ca si cum ar fi schimbul standard pe care-l avem, dar de fapt fiecare client va trebui sa-l rafineze singuri.

Utilizați conexiunile terminalelor. Utilizarea clientului web.

Stabilitatea rețelei devine critică. în cazul nefuncționării sale, activitatea locației se ridică practic.

De asemenea, știu că există probleme cu conectarea și utilizarea imprimantei pentru imprimarea documentelor (de exemplu, actele de cântărire).

Pentru a implementa și utiliza o astfel de opțiune de acces, aveți nevoie de un specialist competent (administrator de sistem).

Când folosim un client web, întâlnim aceleași caracteristici de lucru descrise mai sus pentru conexiunea terminalului. Principala diferență este că utilizatorul se conectează la baza de date printr-un browser web.

PRINCIPAL MINUS PENTRU NOI:

Clientul web interacționează numai cu baza de date NUMAI în modul aplicație gestionată. CROWBAR-ul nostru, din păcate, în acest moment este absolut inoperant în această interfață! Finalizarea acestei interfețe pentru LOMA poate trage de luni de zile, deoarece de fapt, aceasta este dezvoltarea unei noi configurații.







Pentru client, principalul dezavantaj al acestei metode este că, dacă există un număr mare de noduri RIB, încărcarea bazei de date centrale crește de mai multe ori! Volumul tranzacțiilor pe zi poate fi enorm, ceea ce este puțin probabil să afecteze viteza sistemului.

Pro: puteți implementa RIB fără instalarea 1C, economisind cerințele pentru computerele de pe site-uri.

Folosind o configurație suplimentară în BAR.

Ca baze pe site-uri, puteți utiliza o configurație ușoară LOMA, în care vor fi implementate doar cele mai necesare funcționalități pentru a primi și a da socoteală pentru resturi de pe site.

Mecanismul de schimb în acest caz poate fi implementat în două moduri:

1) Ușoare. Folosim un schimb tipic de date universal între configurații în conformitate cu regulile de schimb elaborate. În acest caz, nu folosim mecanismul RIB însuși și planurile de schimb. Ie configurația de pe site nu va avea un semn subordonat, iar schimbul dintre bazele de date va fi întotdeauna FULL (în acest caz se presupune că toate obiectele din baza de date selectate de regulile de schimb vor fi întotdeauna transferate și nu numai cele schimbate). Acest schimb nu se deosebește de transferul obișnuit de date între configurații.

2) Maximul. În acest caz, configurația necesită crearea planurilor de schimb, dezvoltarea subsistemului de schimb și conectarea RIB-ului.

PRINCIPALELE MINUSE PENTRU NOI:

- dezvoltarea unei configurații universale ținând cont de cerințele generale de bază ale clienților este o afacere pe termen lung. Este extrem de dificil să faceți o evaluare. Dacă evaluezi doar subsistemele contabile și auxiliare - apoi aproximativ 2-3 luni. În mod separat, crearea unui subsistem de schimb - de la 1 la 2 luni. Dezvoltarea regulilor de schimb este de la 0,5 la 1 lună (în funcție de necesitatea doar a unor reguli de schimb între centru și site, sau chiar între site-uri).

- sprijinirea și actualizarea acestei configurații, implementarea în ea a cerințelor specifice ale unui anumit client - toate acestea nu reprezintă o povară suplimentară pentru programatori.

Pentru clientul de dezavantaje speciale ale acestei metode, nu văd, cu excepția actualizării a două baze de date în loc de una.

Pro: pe platforme complet separate baza și configurație.

(metoda 3): este posibil să se recomande o conexiune terminală pentru zonele care nu sunt prea îndepărtate de centru, cu un canal de comunicare garantat sigur (puteți organiza un canal duplicat) și dacă este important să primiți informații despre starea de lucruri de pe acel loc.

Deci, cred că, inițial, este necesar să înclinați clienții la prima opțiune, folosind, dacă este necesar, a treia.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: