എന്തും കണക്റ്റ് ചെയ്യുന്നത്

HTTP ഇൻ, HTTP ഔട്ട്, ബുദ്ധിമുട്ടുള്ള ഭാഗങ്ങൾ കൈകാര്യം ചെയ്തത്

ഓരോ ഓട്ടോമേഷൻ ഉപകരണവും ഇന്റഗ്രേഷനുകളുടെ ഒരു എണ്ണം പരസ്യപ്പെടുത്തുന്നു. ആ എണ്ണം എപ്പോഴും വലുതാണ്, എപ്പോഴും തെറ്റായ ചോദ്യമാണ്, കാരണം നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ വേണ്ട സിസ്റ്റം 2014-ൽ പോയവരുടെ ആളാണ് ഇൻ-ഹൗസ് നിർമ്മിച്ചത്. പ്രധാനം ഉപകരണം അവയെല്ലാം അടിയിലുള്ള പ്രോട്ടോക്കോൾ എത്ര നന്നായി സംസാരിക്കുന്നു എന്നതാണ്.

തയ്യാറാക്കിയ കണക്ഷനുകൾ

മിക്ക ബിസിനസുകളും പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനുകൾക്ക് തയ്യാറാക്കിയ ഘട്ടങ്ങളുണ്ട്: ഷോപ്പുകളും മാർക്കറ്റ്പ്ലേസുകളും, അക്കൗണ്ടിംഗും ഇൻവോയ്സിംഗും, സ്പ്രെഡ്‌ഷീറ്റുകളും ഡാറ്റാബേസുകളും, കലണ്ടറുകളും മെയിലും, സ്റ്റോറേജും മെസ്സേജിംഗും, CRM-കളും ഹെൽപ്പ്ഡെസ്ക്കുകളും, പേയ്മെന്റ് പ്രോവൈഡർമാരും ഷിപ്പിംഗ് കാരിയറുകളും. അക്കൗണ്ട് ഒരിക്കൽ അനുവദിക്കുമ്പോൾ ഫീൽഡുകൾ ആ ആപ്ലിക്കേഷന്റെ ഭാഷയിലാണ് പേരിട്ടിരിക്കുന്നത്, അതിന്റെ JSON-ന്റെ ഭാഷയിലല്ല.

ഒരു ആപ്ലിക്കേഷന് പോളിഷ് മാർക്കറ്റിന്റെ പ്രത്യേകതയുണ്ടെങ്കിൽ — KSeF-ക്ക് തയ്യാറായിരിക്കേണ്ട ഒരു ഇൻവോയ്സിംഗ് സിസ്റ്റം, അതിന്റെ ലേബലുകൾ ദേശീയ സ്റ്റാൻഡേർഡ് ആയ ഒരു കാരിയർ — തയ്യാറാക്കിയ ഘട്ടം അതിനെക്കുറിച്ച് അറിയാം, കാരണം കുടുംബം ആ മാർക്കറ്റിലേക്ക് വിറ്റ് പഠിക്കേണ്ടി വന്നു.

പിന്നെ പൊതുവായ കേസ്

ബാക്കി എല്ലാം ഒരു HTTP ഘട്ടമാണ്, ഇവിടെ ഒരു HTTP ഘട്ടം ആശ്വാസ സമ്മാനമല്ല. തയ്യാറാക്കിയ കണക്ഷനുകൾ നിർമ്മിച്ചിരിക്കുന്ന അതേ യന്ത്രസംവിധാനമാണത്, സ്വയം എഴുതാൻ മടുപ്പിക്കുന്ന ഭാഗങ്ങളുടെ അതേ കൈകാര്യത്തോടെ.

മടുപ്പിക്കുന്ന ഭാഗങ്ങൾ

കൈകാര്യം ചെയ്തിരിക്കുന്നു, നിങ്ങൾ വീണ്ടും എഴുതേണ്ടതില്ല

ആധികാരികത ഉറപ്പാക്കൽ

API കീകൾ, ബെയറർ ടോക്കണുകൾ, ബേസിക് ഓത്ത്, റിഫ്രെഷ് ഉള്ള OAuth 2, HMAC റിക്വസ്റ്റ് സൈനിംഗ്, മ്യൂച്വൽ TLS. ഒരു ക്രെഡൻഷ്യൽ ഒരിക്കൽ സംഭരിക്കുന്നു, പേരുകൊണ്ട് റഫർ ചെയ്യുന്നു, ഒരിക്കലും ലോഗിലോ റൺ രേഖയിലോ അച്ചടിക്കുന്നില്ല.

പേജിനേഷൻ

കേഴ്സറുകൾ, പേജ് നമ്പറുകൾ, ഓഫ്‌സെറ്റുകൾ, Link ഹെഡറുകൾ, ശൂന്യമായ അറേ തിരികെ നൽകി അവസാനം അറിയിക്കുന്ന API. ഏത് രൂപമാണെന്ന് പറഞ്ഞാൽ ഘട്ടം മുഴുവൻ സെറ്റും നടക്കുന്നു.

റേറ്റ് ലിമിറ്റുകൾ

ഓരോ കണക്ഷനും ഒരു പരിധി, അത് ഉപയോഗിക്കുന്ന എല്ലാ വർക്ക്ഫ്ലോകളിലും പാലിക്കപ്പെടുന്നു. ഒരു പ്രോവൈഡർ 429 ഉം Retry-After ഉം നൽകുമ്പോൾ, ആവർത്തിച്ച് ശ്രമിക്കുന്നതിന് പകരം ആ സമയം ഘട്ടം കാത്തിരിക്കുന്നു.

പുനഃശ്രമങ്ങളും ബാക്ക്ഓഫും

താൽക്കാലിക പരാജയങ്ങൾ ക്രമേണ വർദ്ധിക്കുന്ന ഇടവേളയോടെയും ഒരു പരിധിയോടെയും വീണ്ടും ശ്രമിക്കപ്പെടുന്നു. ഒരു ഘട്ടം അതിന്റെ ഇൻപുട്ടുകളുടെ ശുദ്ധമായ ഫംഗ്ഷനാണ്, അതിനാൽ പുനഃശ്രമം മുഴുവൻ റൺ വീണ്ടും നടത്തുന്നതിന് പകരം ആ ഘട്ടം മാത്രം വീണ്ടും നടത്തുന്നു.

ബുദ്ധിമുട്ടുള്ള പേലോഡുകൾ

JSON, ഫോം എൻകോഡിംഗ്, XML, സാധാരണ ടെക്സ്റ്റ്, മൾട്ടിപാർട്ട് അപ്‌ലോഡുകൾ. പ്രതികരണങ്ങൾ പേരുകളിലൂടെ റഫറൻസ് ചെയ്യാവുന്ന ഫീൽഡുകളായി പാഴ്സ് ചെയ്യപ്പെടുന്നു — നാല് തലങ്ങൾ താഴെ കൂടി നെസ്റ്റ് ചെയ്തവ ഉൾപ്പെടെ.

ടൈംഔട്ടുകൾ

ഓരോ ഘട്ടത്തിനും ഒരു പരിധി, അതുവഴി ഒരു പതുക്ക ഡിപൻഡൻസിക്ക് പിന്നിലെ എല്ലാം ക്യൂവിൽ കിടക്കുമ്പോൾ ഒരു വർക്കറെ തടഞ്ഞുനിർത്താൻ കഴിയില്ല. പരിധി എത്തുമ്പോൾ എന്ത് സംഭവിക്കണം എന്നത് ഓരോ ഘട്ടത്തിനും അങ്ങാട്ടിന്റെ തീരുമാനമാണ്.

HTTP സംസാരിക്കുന്ന എന്തിനും, സംഭാഷണം ഇതിനകം തുടങ്ങിക്കഴിഞ്ഞു.

വരവുള്ള വെബ്‌ഹുക്കുകൾ, ഗൗരവത്തോടെ

എല്ലാ വർക്ക്ഫ്ലോക്കും അത് ആരംഭിക്കുന്ന ഒരു URL ഉണ്ടാകാം. ആ URL സിഗ്നേച്ചറുകൾ പരിശോധിക്കുന്നു — സാധാരണ പ്രോവൈഡർമാർ ഉപയോഗിക്കുന്ന രൂപങ്ങളിലുള്ള HMAC, അയയ്ക്കുന്നയാൾക്ക് അതുമാത്രം സാധിക്കുന്നിടത്ത് ഒരു പങ്കിട്ട രഹസ്യം. സിഗ്നേച്ചർ പ്രതീക്ഷിക്കുന്ന ഒരു വർക്ക്ഫ്ലോയ്ക്കുള്ള സിഗ്നേച്ചർ ഇല്ലാത്ത അഭ്യർഥന നിരസിക്കപ്പെടുകയും രേഖപ്പെടുത്തപ്പെടുകയും ചെയ്യുന്നു, ശാന്തമായി പ്രോസസ് ചെയ്യപ്പെടില്ല.

ഡീഡ്യൂപ്ലിക്കേഷൻ പേലോഡിന്റെ സ്വന്തം ഐഡന്റിഫയറിന്റെ അടിസ്ഥാനത്തിലാണ്, അതുവഴി അങ്ങാട്ടിന്റെ 200 കൃത്യസമയത്ത് കാണാതെ വീണ്ടും ശ്രമിക്കുന്ന അയയ്ക്കുന്നയാൾക്ക് മൂന്നല്ല, ഒരു റൺ മാത്രം ലഭിക്കുന്നു. തെറ്റായ പേലോഡുകൾ നിരസിച്ച കാരണത്തോടെ സൂക്ഷിക്കപ്പെടുന്നു, കാരണം ഒരു ഓട്ടോമേഷനിലെ വിചിത്രമായ ഇടവേളയുടെ ഏറ്റവും സാധാരണ കാരണം ഒരു ഫീൽഡിനെക്കുറിച്ച് മനസ്സുമാറ്റം വന്ന അയയ്ക്കുന്നയാളാണ്.

CSV മാത്രം സംസാരിക്കുന്ന സിസ്റ്റങ്ങൾ

അവ നിലവിലുണ്ട്. രാവിലെ നാലിന് ഒരു SFTP സെർവറിൽ ഒരു ഫയൽ പ്രത്യക്ഷപ്പെടുന്നു, അല്ലെങ്കിൽ ഒരു അറ്റാച്ച്മെന്റായി വരുന്നു, അല്ലെങ്കിൽ ഒരു പങ്കിട്ട ഫോൾഡറിൽ ഇടുന്നു. ഒരു വർക്ക്ഫ്ലോയ്ക്ക് അത് നിരീക്ഷിക്കാം, വായിക്കാം, ഓരോ വരിയെയും ഒരു റെക്കോർഡായി കണക്കാക്കാം — ബൈറ്റ്-ഓർഡർ മാർക്കും സെമികോളൺ വിഭജനക്കാരും പോളിഷിലുള്ള ഹെഡർ വരിയുമുള്ള ഫയൽ ഉൾപ്പെടെ, കാരണം എക്സ്പോർട്ട് യഥാർത്ഥത്തിൽ അങ്ങനെയാണ് കാണുന്നത്.

മറുവശത്തേക്കും പോകാം: ഒരു വർക്ക്ഫ്ലോയ്ക്ക് ഒരു ഫയൽ തയ്യാറാക്കി മറ്റേ സിസ്റ്റം പ്രതീക്ഷിക്കുന്ന സ്ഥലത്ത് വയ്ക്കാം, 2006-ലെ ഒരു സോഫ്റ്റ്വെയറിന് പലപ്പോഴും ഇതുമാത്രമാണ് ഇന്റർഫേസ്.

രാത്രി സപ്ലയർ ഫീഡ്SFTP → HTTP

⚡ട്രിഗർ04:02സപ്ലയറിന്റെ SFTP-യിൽ പുതിയ ഫയൽ: stock-2026-09-09.csv.
2പാഴ്സ്സെമികോളണുകൾ, ബൈറ്റ്-ഓർഡർ മാർക്ക്, പോളിഷ് ഹെഡറുകൾ. 4 118 വരികൾ.
3സാധാരണവൽക്കരണംകറൻസി കോഡുകൾ റഫറൻസ് ഡാറ്റയുമായി പരിശോധിച്ചു; രണ്ട് അസാധുവായി നിരസിച്ചു.
4പുഷ് ചെയ്യുക2.9 sHTTP PATCH 200 ബാച്ചുകളായി, റേറ്റ് പരിധി പാലിച്ചു.
!അപവാദങ്ങൾഒരാൾക്കുവേണ്ടി രണ്ട് വരികൾ ഫയൽ ചെയ്തു, വരി നമ്പറും കാരണവും സഹിതം. ബാക്കി 4 116 വരികൾ കടന്നുപോയി.

ഒരു മോഡലിനെ വിളിച്ച ഘട്ടങ്ങൾ: 0ഈ റണ്ണിന്റെ ചെലവ്: ഒന്നുമില്ല

ക്രെഡൻഷ്യലുകൾ എവിടെയാണ്

എൻക്രിപ്റ്റ് ചെയ്തത്, പേരിലൂടെ റഫറൻസ് ചെയ്തത്, അവ ഉടമസ്ഥതയിലുള്ള വർക്ക്സ്പേസിലേക്ക് പരിധിവലിക്കപ്പെട്ടത്, ഒരിക്കലും ഒരു റൺ ലോഗിലോ പിശക് സന്ദേശത്തിലോ സപ്പോർട്ട് സംഭാഷണത്തിലോ പ്രദർശിപ്പിക്കാത്തത്. ഒരു റൺ റെക്കോർഡ് ഒരു ഘട്ടം supplier-sftp ആയി പ്രാമാണീകരിച്ചു എന്ന് കാണിക്കുന്നു; supplier-sftp എന്താണെന്ന് കാണിക്കുന്നില്ല.

മുപ്പത് ക്ലയന്റുകൾക്കായി ഒരു വർക്ക്ഫ്ലോ നടത്തുന്ന ഒരു ഏജൻസി ഓരോ ക്ലയന്റിനും അതിന്റേതായ ക്രെഡൻഷ്യൽ സെറ്റ് നൽകുന്നു, വർക്ക്ഫ്ലോ രഹസ്യത്തെയല്ല സെറ്റിനെയാണ് റഫറൻസ് ചെയ്യുന്നത്. ഒരു കീ പുതുക്കുന്നത് ഒരിടത്ത് ഒരു എഡിറ്റ് മാത്രമാണ് — ഏജൻസികൾ ഇവിടേക്ക് വരുന്നതിന്റെ ഭൂരിഭാഗം കാരണവും ഇതാണ്.

അറിയേണ്ട പരിധി: ഒരു ഇന്റർഫേസുമില്ലാത്ത സിസ്റ്റം — API ഇല്ല, വെബ്‌ഹുക്ക് ഇല്ല, ഫയൽ ഡ്രോപ്പ് ഇല്ല, ഒരു ബ്രൗസറിൽ ക്ലിക്ക് ചെയ്യുന്ന ഒരാൾ മാത്രം — ഇതുകൊണ്ടോ മറ്റേതെങ്കിലും സത്യസന്ധമായ മാർഗത്തിന്റെ കൊണ്ടോ ഓട്ടോമേറ്റ് ചെയ്യാൻ കഴിയില്ല. ഇവിടെ ഒരു ഉപയോക്താവിനെ അനുകരിക്കുന്ന ഹെഡ്‌ലെസ് ബ്രൗസർ ഇല്ല, കാരണം മറുവശം ഒരു ബട്ടൺ നീക്കുമ്പോൾ അത് ആദ്യമേ തകരും, ശാന്തമായി തകരും.