Frymëzuesit pas zhvillimit të shërbimit të statistikave për Tinkoff Investments ishin:

• artikull në Habré “Çfarë nuk po thonë investimet Tinkoff” 
• analiza e dëshirave të përdoruesve të platformës
• një artikull për llogaritjen e komisioneve . 

Çfarë do të diskutohet?

• Vetëm pjesa e aplikuar rreth zhvillimit.
• Njohuri dhe përvojë reale, të cilat janë shumë të rëndësishme në punën me instrumentet financiare.
• Pasqyrë e çështjeve për të punuar

Pra, unë dua të llogaris statistikat e tregtisë dhe ta bëj atë në një mënyrë të përshtatshme. 

Zhvillimi i një shërbimi statistikor hap pas hapi: 

1. Lidhja me Tinkoff Invest API
2. Vizatimi i të dhënave nga Tinkoff Invest API në një shfletues
3. Marrja e raporteve dhe transaksioneve të ndërmjetësimit
4. Llogaritja dhe prodhimi i informacionit me interes
5. Konkluzione dhe plane për të ardhmen

Lidhja me Tinkoff Invest API

Për t’u lidhur me API-në, mund të merrni çdo sdk nga dokumentacioni https://github.com/Tinkoff/investAPI#sdk . Ose paketa npm ` tinkoff-sdk-grpc-js` . Është e rëndësishme që paketa të përditësohet në versionin më të fundit nga zhvilluesit. Instaloni

npm dhe tinkoff-sdk-grpc-js

Duke kontrolluar

const {createSdk } = kerkoj(‘tinkoff-sdk-grpc-js’);   // Token që mund të merret si kjo  const TOKEN = ‘YOURAPI’;   // Emri i aplikacionit me të cilin mund të gjendeni në regjistrat e TCS. const appName = ‘tcsstat’;   const sdk = createSdk(TOKEN, emri i aplikacionit); (async () => { console.log (prit sdk.users.getAccounts()); })();

Rezultati: një listë e llogarive tuaja do të shfaqet në tastierë. Për shembull, le të analizojmë nuancat:

• Në listën e llogarive ka një “bankë investimi”, me të cilën nuk mund të punoni duke përdorur API
• Ju lutemi vini re se fushat vijnë në camelCase, ndërsa në dokumentacion këto fusha janë paraqitur në nën_score. 
• Kështu do të jetë kudo, kështu që nuk mund të merrni dhe kopjoni thjesht një fushë nga dokumentacioni.

E dobishme:

• Këtë kod mund ta gjeni në degën e projektit

https://github.com/pskucherov/tcsstat/tree/step1 https://github.com/pskucherov/tcsstat/compare/step1   

Vizatimi i të dhënave nga Tinkoff Invest API në një shfletues

Mora next.js dhe socket.io. Ky nuk është një rekomandim i fortë, zgjidhni sipas gjykimit tuaj. 

npx create-next-app@latest npm dhe socket.io socket.io-client

Ne vazhdojmë menjëherë te hapi i miqësisë next+socket+investapi dhe shiko seksionin e dobishme të këtij hapi për të gjitha detajet.  Unë do të përshkruaj detajet: 

• Në anën e nodejs (server), ekziston një skedar pages/api/investapi.js. Këtu krijojmë serverin socket.io dhe lidhemi me investapi.
• Në anën e shfletuesit (klientit), ne lidhemi me serverin përmes një fole dhe kërkojmë të dhëna llogarie nga ndërmjetësi. 
• Ne marrim të dhëna nga ndërmjetësi në server, pastaj ia dërgojmë klientit. Kur ato merren në klient, ato shfaqen në shfletues. 

Rezultati:  në tastierën e shfletuesit mund të shohim informacione rreth llogarive. Kjo do të thotë, në hapin e fundit, ne pamë informacione rreth llogarive në tastierën e serverit (nodejs), në hapin aktual, ne ia transferuam këtë informacion klientit (shfletuesit).

Tani le ta bëjmë atë në mënyrë që të mund të zgjidhni një llogari nga shfletuesi, dhe nëse nuk ka shenjë, atëherë një gabim dërgohet në tastierë. Puna është e thjeshtë dhe asgjë e re, kështu që unë jap vetëm lidhje për commits

1. https://github.com/pskucherov/tcsstat/commit/7e1ac57061e5e971588479015b06d8814d6609a9
2. https://github.com/pskucherov/tcsstat/commit/b28ac973a57494f5232589b4cb6b9fb13b8af759 

E dobishme:

• Si të bëni miq tjetër dhe prizë përshkruhet në detaje këtu . 
• Kodi i miqësisë next+socket+investapi:

https://github.com/pskucherov/tcsstat/commit/a443a4ac1bb4f0aa898f638128755fe7391ee381 Për të cilët sa më sipër është e vështirë, atëherë mbetemi në këtë fazë dhe merremi me kodin. Nëse keni pyetje – pyesni. https://github.com/pskucherov/tcsstat/tree/step2 https://github.com/pskucherov/tcsstat/compare/step1…step2

Marrja e raporteve dhe transaksioneve të ndërmjetësimit

Ekzistojnë tre mënyra për të marrë raporte dhe transaksione ndërmjetësimi

1. GetBrokerReport
2. GetDividendsForeignIssuer
3. GetOperationsByCursor

Që në fillim është e rëndësishme të dini: 

• Raporti i ndërmjetësimit gjenerohet në modalitetin T-3, d.m.th. tregtimet shfaqen atje pas ekzekutimit të tyre aktual. 
• Prandaj, nëse e kërkoni këtë raport për dy ditët e fundit, ai do të jetë gati për tre ditë. 
• Për të bërë marrëveshje për ditët e fundit, ne përdorim metodën për marrjen e operacioneve, por mos harroni se ID dhe përmbajtja e tyre mund të ndryshojnë pas formimit të raportit të ndërmjetësimit.

GetBrokerReport

Për të marrë një raport brokerimi, duhet të merrni ID-në e llogarisë, datën e fillimit dhe datën e përfundimit të raportit, por jo më shumë se 31 ditë. Ne dërgojmë një kërkesë për të gjeneruar një raport në API në gjenerimin e _broker_report_request , merrni një ID-së si përgjigje. Pas kësaj, duke përdorur këtë taskId, marrim të dhëna nga get _broker_report_response.

Le të fillojmë të shkruajmë kodin

Metoda për marrjen e datës, duke marrë parasysh zbritjen nga data aktuale

const getDateSubDay = (nëndita = 5, fillimi = e vërtetë) => {     const data = new Date();     data.setUTCDate(data.getUTCDate() – nënDita);       if (fillimi) {         date.setUTCHours(0, 0, 0, 0);     } else {         date.setUTCHours(23, 59, 59, 999);     }       data e kthimit; };

Kërkesa për gjenerim të raportit 

const brokerReport = prit (sdk.operations.getBrokerReport)({         genereBrokerReportRequest: {             accountId,             from,             to,         }, });

Rezultati:

• Si rezultat i ekzekutimit të parë të komandës, marrim taskId. 
• Raporti fillon të gjenerohet nga ana e ndërmjetësit. Kur është gati nuk dihet, presim dhe tërheqim periodikisht taskId-in në pritje të raportit.
• Pse? Sepse nëse raporti nuk është gati, ai hedh një gabim. Nëse raporti nuk është gati nga ana e ndërmjetësit, atëherë ky është një gabim në kodin tuaj. Ju lutemi përpunoni: 30058|INVALID_ARGUMENT|detyra nuk është përfunduar ende, ju lutemi provoni përsëri më vonë

Kodi për pritjen dhe marrjen e një raporti duket diçka e tillë.

const timer = async time => {     return new Promise(resolve => setTimeout(resolve, time)); }   const getBrokerResponseByTaskId = async (taskId, faqe = 0) => {     provoni {         return await (sdk.operations.getBrokerReport)({             getBrokerReportRequest: {                 taskId,                 page,             },         });     } catch (e) {         console.log(‘prit’, e);         kohëmatësi i pritjes (10000);         kthimi në pritje getBrokerResponseByTaskId(taskId, faqe);     } };

Pastaj ndodh e njëjta magji. Ne e ndalojmë skriptin tonë, e fillojmë përsëri, nuk kemi një ID ID. Ne ekzekutojmë kodin me kërkesën taskId, por nuk marrim më taskId, por menjëherë raportin. Magjike! Dhe gjithçka do të ishte mirë nëse do të ishte gjithmonë kështu. Por në një muaj nuk do të ketë fare të dhëna. E dobishme :

• Një pjesë e teorisë është përshkruar këtu dhe këtu .
• Duke bashkuar kodin, drafti do të duket diçka si kjo.

https://github.com/pskucherov/tcsstat/tree/step3.1 https://github.com/pskucherov/tcsstat/compare/step3.1

• Nëse dikush e has këtë, atëherë mirë se vini në këtë çështje . Pasi ta riparojnë këtë magji, ajo do të humbasë fuqinë e saj dhe do të jetë disi ndryshe. Por në momentin aktual (21.03.2023) funksionon ashtu.

GetDividendsForeignIssuer

Dikush mund të mendojë se metoda është e ngjashme me atë të mëparshme dhe ju mund të përdorni një metodë të vetme në të cilën ndryshoni vetëm emrin e operacioneve. Por ata nuk e morën me mend!  Emërtimi atje është shumë i ndryshëm si në metoda ashtu edhe në informacionin e kthyer. Dhe numërimi i faqeve fillon nga 0, pastaj nga 1. Për të mos u ngatërruar në të gjitha këto, është më e lehtë të shkruash dy metoda të ndryshme. E cila është e çuditshme, sepse logjika e punës është e njëjtë. Pështyja për një kohë të gjatë kur u përpoqa të bëja një metodë dhe kishte më pak kod. Këtu nuk do të ketë shembuj.

GetOperationsByCursor

I preferuari im nga të tre. Edhe pse jo më e sakta, por më adekuate. Ne bëjmë një kërkesë që nga fillimi i krijimit të një llogarie deri në datën maksimale të mundshme (mbyllja e një llogarie ose ajo aktuale). Marrim përgjigjen, marrim kursorin dhe rikërkojmë për sa kohë ka të dhëna.  Dhe kodi është më konciz sesa në shembujt e mësipërm.

const timer = async time => {     return new Promise(resolve => setTimeout(resolve, time)); }   const getOperationsByCursor = async (sdk, accountId, nga, te, kursori = ”) => {     provo {         const reqData = {             accountId,             nga,             në,             limit: 1000,             gjendje: sdk.OperationState.OPERATION_STATE_EXECUTED, pa             Komisione, false:             withoutTrades: false,             without Overnights: false,             kursori,         };           kthimi në pritje sdk.operations.getOperationsByCursor(reqData);     } catch (e) {         await timer (60000);         kthimi në pritje getOperationsByCursor(sdk, accountId, nga, në, kursori = ”);     } };

Drafti për të ekzekutuar është këtu: https://github.com/pskucherov/tcsstat/tree/step3.3 https://github.com/pskucherov/tcsstat/compare/step3.3   Tani jemi gati të shtojmë operacionet e marrjes në aplikimin tonë. Nëse bëhet si duhet, atëherë duhet të merrni raporte ndërmjetësimi për të gjithë ekzistencën e llogarisë. Dhe për të dhënat që mungojnë, të njëjtat T-3, ringarkohen nga operacionet. Por kjo mund të ndahet në një artikull të veçantë.   Nga nuancat kryesore që do të hasni është të ngjitni operacionet dhe një raport ndërmjetësimi.

•  Nëse sot keni marrë një raport brokerimi dhe transaksione për datat e kërkuara, vendosni të gjitha në bazën e të dhënave, atëherë nuk ka probleme. 
• Do të keni probleme nesër kur të merrni pjesën tjetër të të dhënave nga raporti dhe operacionet dhe të vendosni t’i sinkronizoni ato me bazën e të dhënave ekzistuese. 
• Shumë nuanca rreth mospërputhjes ose ndryshimit të ID-së pas përpunimit
• Pastaj për tregun OTC, ID-të nuk përputhen fare.
•  Si dhe nuancat e instrumenteve sinkronizuese, të cilat përsëri nuk përkojnë, për shkak të veçorive të API-së. Por kjo është një histori tjetër.

Le të shtojmë marrjen e informacionit rreth operacioneve në aplikacionin tonë. Pyetja kryesore do të jetë se ku do të përpunohen dhe ruhen të dhënat.

•  Nëse e bëni për veten tuaj, do të konsumoni të njëjtat të dhëna nga pajisje të ndryshme. Pastaj ju duhet të përpunoni dhe ruani të dhënat në server.
• Nëse keni shumë të dhëna të ndryshme të konsumuara nga shumë përdorues të ndryshëm, atëherë duhet të vendosni se çfarë është më e rëndësishme: shpejtësia e përdoruesve apo kursimi i hekurit në anën tuaj. Kushdo që mund të përballojë një sasi të pafundme hardueri, numëron gjithçka në serverin e tij dhe e bën atë super të shpejtë për përdoruesit, duke kursyer burimet e përdoruesit, si bateria dhe trafiku, gjë që është shumë e rëndësishme për telefonat.

Nga ana tjetër, numërimi në shfletues nuk është zgjidhja më optimale në parim. Prandaj, atë që nuk është e shtrenjtë, ne e konsiderojmë atë në serverin tonë. Pjesën tjetër ia lëmë klientit. Unë me të vërtetë dua të marr dhe llogaris komisionin në server. Por këtu vjen nuanca e quajtur “interaktivitet”. Le të themi se keni mijëra operacione dhe duhen pesë minuta për t’i marrë ato. Çfarë do të ketë përdoruesi në këtë moment? Spiner? Përparim? Infa rreth sa u ngarkua? Është ideale të përdoret “pritja aktive” kur përdoruesi në proces mund të shohë tashmë diçka. Këtu është Rezultati:

• Ngarkimi i faqes
• Kërkohen të gjitha faturat
• Pas kësaj kërkohen të gjitha transaksionet me komisione për transaksionet e kryera për të gjitha llogaritë. Ndërsa të dhënat merren, ato paraqiten në shfletues.

Për të mos filtruar të dhënat në ngjarje çdo herë, ne tërheqim ngjarjen tonë për secilën llogari. Si kjo:

socket.emit(‘sdk:getOperationsCommissionResult_’ + accountId, {                 artikuj: data?.artikuj,                 në progres: Boolean(nextCursor), });

Drafti për të nisur është këtu: https://github.com/pskucherov/tcsstat/tree/step3 https://github.com/pskucherov/tcsstat/compare/step2…step3 Duke vazhduar. Është mirë që e lexuat këtë rresht! 

Llogaritja dhe prodhimi i informacionit me interes

Varet se kujt i duhet çfarë informacioni. Prandaj, unë ju tregoj menjëherë nuancat kryesore që do të hasni.

Puna me çmimet 

Të gjithë ata që punojnë me financa e dinë që transaksionet e parave duhet të kryhen vetëm me numra të plotë. Për shkak të pasaktësisë së vlerave pas pikës dhjetore dhe gabimit kumulativ me një numër të madh operacionesh. Kjo është arsyeja pse të gjitha çmimet janë paraqitur në formatin e mëposhtëm MoneyValue

fushë	lloji	Përshkrim
valutë	varg	Vargu i kodit të monedhës ISO
njësi	int64	Pjesa e plotë e shumës, mund të jetë një numër negativ
nano	int32	Pjesa thyesore e shumës, mund të jetë një numër negativ

Ne i përpunojmë ato veçmas, pastaj i sjellim në vlerën e çmimit:

kuotim.njësi + kuotim.nano / 1e9

Kostoja e kontratave të së ardhmes

Çmimi i kontratave të së ardhmes paraqitet në pikë, kur keni një të ardhme në monedhë, duhet të dini normën. Dhe sigurisht çmimi në pikë dhe hapi i çmimit. Kur llogaritni fitimin nga transaksionet, kjo mund të shkrepë, sepse. nëse llogaritni shumën totale duke shumëzuar çmimin me sasinë. Këtu duhet të keni kujdes. Tani për tani, do të shohim se si do të shkojë. Kjo vlen për të ardhmen e monedhës, në vende të tjera gjithçka është në rregull me këtë.

treg OTC

Ky treg ka shumë veçori, kështu që le të studiojmë veçmas operacionet mbi të. Kur të filloni të sinkronizoni operacionet, do të rezultojë se duhet të sillni figi / tiker në të njëjtën formë në mënyrë që të përputhet saktë me instrumentin. Kur filloni ta sinkronizoni këtë me raportin e ndërmjetësimit, do të rezultojë se ID-ja e tregtimit të të njëjtit transaksion ka shkronja në fillim në transaksione dhe ato nuk janë në raportin e ndërmjetësimit. Prandaj, ato nuk mund të krahasohen … ahem-ahem … me krahasim! Përputhja me kohën e tregtimit, shenjën dhe përputhjen që një tradeId gjendet në një tjetër. E drejtë, nuk e di. Kushdo që ndeshet me këtë dhe kush kujdeset për të, të vijë në këtë çështje ose të fillojë një të re.

Veprime matematikore në vegla

Është e pamundur, pa shikuar, të kryhen veprime matematikore me të gjithë listën. Për të mos shtuar ngrohtë në soft, ne gjithmonë kontrollojmë monedhën dhe përpunojmë vetëm nëse jemi të sigurt që monedha përputhet dhe pikët konvertohen në monedhën e dëshiruar. Të armatosur me njohuri për punën me numrat e bankave, ne do të llogarisim komisionin e shpenzuar për secilën prej llogarive. Si kjo: https://github.com/pskucherov/tcsstat/tree/step4 https://github.com/pskucherov/tcsstat/compare/step3…step4    

Microservice është gati!

https://github.com/pskucherov/tcsstat Si detyrë shtëpie, mund të kontrolloni nëse shërbimi funksionon me një lidhje të ngadaltë, kur lidhjet janë të prishura, kur Interneti është shkëputur, kur ka gabime ose kufij të skaduar nga ana e ndërmjetësit. 

Konkluzione dhe plane për të ardhmen

• Mësoi rreth operacioneve bazë dhe punës me Invest API
• Koha e kaluar ~ 10 orë
• Niveli i vështirësisë ~ i ri+ / i mesëm i ulët 

Nëse vazhdoni të përsosni mikroshërbimin, mund të përfundoni me diçka të tillë

https://opexbot.info

Ky është zhvillimi im, për ata që përtojnë të kuptojnë, vrapojnë dhe llogarisin vetë. Kam në plan të shtoj analitikë atje me kërkesë të përdoruesve.   Nëse ju pëlqeu artikulli, atëherë regjistrohuni në kanalin tim të telegramit .