Microsoft Teams டெவலப்பர்கள், ஒவ்வொரு விரிவாக்கத்தையும் (extension) "bot" என்று அழைப்பது இப்போது உற்பத்தித் தரத்திலான தோல்விகளுக்கு (production-grade failures) வழிவகுக்கும் என்று எச்சரிக்கப்படுகிறார்கள். 2026-இல், இந்தத் தளத்தின் சொந்த வரம்புகள்—ஒரு செய்திக்கு பதிலளிக்க 10 முதல் 15 வினாடிகள் மட்டுமே—தவறாக வடிவமைக்கப்பட்ட bots-களை timeout புயல்களாக (timeout storms) மாற்றிவிடும், இது குழுக்களைத் தங்கள் పైப்லைன்களை (pipelines) மறுவடிவமைப்பு செய்ய நிர்ப்பந்திக்கிறது.

இந்த வேறுபாடு ஏன் முக்கியமானது

Teams மூன்று வகையான விரிவாக்கங்களை வழங்குகிறது, ஒவ்வொன்றும் ஒரு மாறுபட்ட தொடர்பு முறையை (interaction pattern) உருவாக்கப்பட்டுள்ளது. அவற்றை ஒன்றுடன் ஒன்று கலப்பது தவறான runtime, தவறான SDK மற்றும் தவறான அளவிடுதல் மாதிரியை (scaling model) திணிக்கிறது.

Teams apps, bots, மற்றும் agents – அவை என்ன

  • Teams apps – Teams கிளையண்டிற்குள் இருக்கும் surface tabs, நிலையான பக்கங்கள் (static pages), அல்லது எளிய UI கூறுகள் (UI components). இவை அடிப்படையில் web apps: stateless, தேவைப்படும்போது render செய்யப்படும், மற்றும் மற்ற HTTP சேவைகளைப் போலவே host செய்யப்படும். இதில் உரையாடல் ஓட்டம் (conversational flow) எதிர்பார்க்கப்படுவதில்லை.
  • Bots – Bot Framework SDK மூலம் உருவாக்கப்படுபவை, bots ஸ்கிரிப்ட் செய்யப்பட்ட உரையாடல்களைப் (scripted dialogs) பின்பற்றுகின்றன. அவற்றின் தர்க்கம் (logic) ஒரு தீர்மானிக்கப்பட்ட (deterministic) if/else மரமாகும், இது வரும் செயல்பாட்டின் (incoming activity) அடிப்படையில் அடுத்த பதிலைத் தீர்மானிக்கிறது. முடிவுப் பாதை முன்கூட்டியே அறியப்படுவதால், பதில் இந்தத் தளத்தின் குறுகிய timeout காலத்திற்குள் அமைகிறது.
  • Agents – ஒரு உயர்நிலை இலக்கு (high-level objective), கருவிகளின் தொகுப்பு (set of tools), மற்றும் ஒரு LLM (large language model) ஆகியவற்றைப் பெறும் இலக்கு சார்ந்த அமைப்புகள் (goal-driven entities). Agents SDK அல்லது Semantic Kernel-ஐப் பயன்படுத்தி, LLM எந்தக் கருவியைப் பயன்படுத்த வேண்டும், எந்த வரிசையில் பயன்படுத்த வேண்டும் மற்றும் பயனரிடம் எப்போது விளக்கம் கேட்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. இதன் ஓட்டம் மாறும் தன்மை கொண்டது (dynamic), பெரும்பாலும் பல வெளிப்புற அழைப்புகள் (external calls) மற்றும் அதிகப்படியான பகுத்தறிவை (heavy reasoning) கோருகிறது.

இந்த வேறுபாடு மிகத் தெளிவானது: ஒரு bot என்பது தீர்மானிக்கப்பட்டது (deterministic); ஒரு agent என்பது நிகழ்தகவு சார்ந்தது (probabilistic) மற்றும் runtime-இல் கருவி அழைப்புகளை ஒருங்கிணைக்கிறது (orchestrates tool calls).

timeout பொறி

டெவலப்பர்கள் அதிகப்படியான பகுத்தறிவை—LLM prompts, தரவுத்தளத் தேடல்கள் (database lookups), அல்லது வெளிப்புற API அழைப்புகள்—நேரடியாக ஒரு bot-ன் செய்தி கையாளியில் (message handler) இணைக்கும்போது, Teams அந்த கோரிக்கை அதன் 10-15 வினாடி கால வரம்பைத் தாண்டி நீடிப்பதை உணர்கிறது. தளம் அந்தப் பதிலைத் தடுத்துவிட்டு மீண்டும் முயற்சிக்கும் (retry), இது மீண்டும் மீண்டும் வேலைகள் நடப்பதற்கும் (duplicate work) மற்றும் throttling எனப்படும் வேகக் குறைப்பிற்கும் வழிவகுக்கும். இதன் அறிகுறி அவ்வப்போது ஏற்படும் "bot not responding" பிழை போலத் தோன்றும், ஆனால் அதன் மூலக் காரணம் கட்டமைப்பு சார்ந்தது (architectural).

உற்பத்தித் தயார் நிலையில் உள்ள async pipeline-ஐ உருவாக்குதல்

  1. Webhook நுழைவுப் புள்ளி (entry point) – bot-ன் HTTP endpoint Teams செயல்பாட்டைப் பெற்று உடனடியாகப் பெற்றதை உறுதிப்படுத்துகிறது (acknowledges receipt).
  2. நிகழ்வை வரிசைப்படுத்துதல் (Queue the event) – handler அந்தத் தரவை (payload) Azure Service Bus போன்ற ஒரு நிலையான வரிசையில் (durable queue) சேர்க்கிறது.
  3. Background worker – ஒரு Azure Durable Function, Service Bus trigger, அல்லது ஏதேனும் ஒரு நீண்ட நேரம் இயங்கும் worker அந்தச் செய்தியைப் பெற்று, LLM reasoning அல்லது tool orchestration-ஐச் செய்து, Bot Framework-ன் proactive messaging API மூலம் இறுதிப் பதிலைத் Teams-க்குத் திருப்பி அனுப்புகிறது.

தொடக்க Webhook உடனடியாகப் பதிலளிப்பதால், Teams ஒருபோதும் அதன் timeout எல்லையைத் தொடாது, மேலும் கடினமான வேலைகள் அதன் சொந்த வேகத்தில் தொடரும். Queue திடீர் அதிகரிப்புகளைத் (spikes) தாங்கும், மேலும் பணி நிலுவையின் (backlog) அளவைப் பொறுத்து workers தானாகவே அளவடையும் (auto-scale).

விரைவான முடிவு வழிகாட்டி (the whiteboard test)

  • நீங்கள் எந்தக் குறியீட்டையும் (code) எழுதுவதற்கு முன்பே முழுமையான முடிவு மரத்தை (decision tree) வரைய முடியுமா? ஆம் → ஒரு bot-ஐ உருவாக்குங்கள். தீர்மானிக்கப்பட்ட ஓட்டம் (Deterministic flow) Bot Framework மாதிரியில் பொருந்தும் மற்றும் பதில் அளிக்கும் காலத்திற்குள் இருக்கும்.
  • சிக்கல் ஒரு உயர்நிலை இலக்கு மற்றும் சாத்தியமான கருவிகளின் பட்டியலால் வரையறுக்கப்படுகிறதா? ஆம் → ஒரு agent-ஐ உருவாக்குங்கள். LLM திட்டமிட்டு கருவிகளை அழைக்கட்டும்; திட்டமிடும் பணியை ஒரு background worker-க்கு மாற்றவும்.

அடுத்து கவனிக்க வேண்டியவை

இந்த வழிகாட்டுதல் Azure-இல் புத்திசாலித்தனமான Teams தீர்வுகளை உருவாக்கும் .NET 9 டெவலப்பர்களுக்கான தொடரின் முதல் பாகமாகும்.

நீங்கள் ஏற்கனவே Teams logs-இல் “Bot timed out” பிழைகளைக் கண்டால், அதற்கான தீர்வு எளிது: webhook-ஐ கடினமான பணிகளிலிருந்து பிரிக்கவும் (decouple), ஒரு queue-driven worker முறையைப் பின்பற்றவும், மற்றும் தொடக்கத்திலிருந்தே சரியான extension வகையைத் தேர்ந்தெடுக்கவும். தளத்திற்கு ஒரு timeout வரம்பு உள்ளது, ஆனால் உங்கள் கட்டமைப்பு (architecture) அதைத் தவிர்க்க முடியும்.

முக்கியக் கருத்து (Takeaway): ஒரு Teams extension-ஐ bot என்று தவறாகக் குறிப்பிடுவது, Teams-ஆல் தாங்க முடியாத ஒரு synchronous வடிவமைப்பைத் திணிக்கிறது. கோரிக்கையை (request) பகுத்தறிவிலிருந்து (reasoning) பிரிக்கவும், சரியான SDK-வைத் தேர்ந்தெடுக்கவும், அதன் பின்னணியில் உள்ள மூளை ஒரு LLM-ஆல் இயங்கும் agent ஆக இருந்தாலும் உங்கள் Teams தீர்வு துரிதமாகச் செயல்படும்.