defineLogicFunction
عرّف الدوال المنطقية ومشغّلاتها
defineLogicFunction
عرّف الدوال المنطقية ومشغّلاتها
كل ملف وظيفة يستخدم أنواع المشغّلات المتاحة:يحتوي نوع
في معالجك، يمكنك الوصول إلى الرؤوس المُمرَّرة بهذه الطريقة:النقاط الرئيسية:
defineLogicFunction() لتصدير تكوين مع معالج ومشغّلات اختيارية.src/logic-functions/createPostCard.logic-function.ts
- httpRoute: يعرِض وظيفتك على مسار وطريقة HTTP تحت نقطة النهاية
/s/:
مثال:path: '/post-card/create'يمكن استدعاؤه عبرhttps://your-twenty-server.com/s/post-card/create
- cron: يشغّل وظيفتك على جدول باستخدام تعبير CRON.
- databaseEvent: يعمل على أحداث دورة حياة كائنات مساحة العمل. عندما تكون عملية الحدث هي
updated، يمكن تحديد الحقول المحددة المراد الاستماع إليها في مصفوفةupdatedFields. إذا تُركت غير معرّفة أو فارغة، فسيؤدي أي تحديث إلى تشغيل الدالة.
مثال:person.updated،*.created،company.*
يمكنك أيضًا تنفيذ دالة يدويًا باستخدام CLI:يمكنك متابعة السجلات باستخدام:
حمولة مشغل المسار
عندما يستدعي مُشغِّل المسار وظيفتك المنطقية، فإنها تتلقّى كائنRoutePayload الذي يتبع صيغة AWS HTTP API v2.
استورد نوع RoutePayload من twenty-sdk:RoutePayload على البنية التالية:| الخاصية | النوع | الوصف | مثال |
|---|---|---|---|
headers | Record\<string, string | undefined> | رؤوس HTTP (فقط تلك المدرجة في forwardedRequestHeaders) | انظر القسم أدناه |
queryStringParameters | Record\<string, string | undefined> | معلمات سلسلة الاستعلام (تُضمّ القيم المتعددة باستخدام فواصل) | /users?ids=1&ids=2&ids=3&name=Alice -> { ids: '1,2,3', name: 'Alice' } |
pathParameters | Record\<string, string | undefined> | معلمات المسار المستخرجة من نمط المسار | /users/:id, /users/123 -> { id: '123' } |
المحتوى | object | null | جسم الطلب المُحلَّل (JSON) | { id: 1 } -> { id: 1 } |
isBase64Encoded | قيمة منطقية | ما إذا كان جسم الطلب مُرمَّزًا بترميز base64 | |
requestContext.http.method | string | طريقة HTTP (GET, POST, PUT, PATCH, DELETE) | |
requestContext.http.path | string | المسار الخام للطلب |
forwardedRequestHeaders
افتراضيًا، لا تُمرَّر رؤوس HTTP من الطلبات الواردة إلى دالتك المنطقية لأسباب أمنية. للوصول إلى رؤوس محددة، أدرِجها في مصفوفةforwardedRequestHeaders:تُحوَّل أسماء الرؤوس إلى أحرف صغيرة. يمكنك الوصول إليها باستخدام مفاتيح بأحرف صغيرة (على سبيل المثال،
event.headers['content-type']).إتاحة دالة كأداة
يمكن إتاحة الدوال المنطقية بوصفها أدوات لوكلاء الذكاء الاصطناعي وسير العمل. عند تمييز دالة كأداة، تصبح قابلة للاكتشاف بواسطة ميزات الذكاء الاصطناعي في Twenty ويمكن استخدامها في أتمتة سير العمل.لتمييز دالة منطقية كأداة، عيِّنisTool: true:src/logic-functions/enrich-company.logic-function.ts
- يمكنك دمج
isToolمع المشغِّلات — إذ يمكن للدالة أن تكون أداة (قابلة للاستدعاء من قِبل وكلاء الذكاء الاصطناعي) وأن تُشغَّل بواسطة الأحداث في الوقت نفسه. toolInputSchema(اختياري): كائن JSON Schema يصف المعلمات التي تقبلها دالتك. يُحسَب المخطط تلقائيًا من خلال تحليل ساكن للشيفرة المصدرية، ولكن يمكنك تعيينه صراحةً:
اكتب
description جيدًا. يعتمد وكلاء الذكاء الاصطناعي على حقل description الخاص بالدالة لتحديد وقت استخدام الأداة. كن محددًا بشأن ما تفعله الأداة ومتى ينبغي استدعاؤها.definePostInstallLogicFunction
تعريف دالة منطقية لما بعد التثبيت (واحدة لكل تطبيق)
definePostInstallLogicFunction
تعريف دالة منطقية لما بعد التثبيت (واحدة لكل تطبيق)
دالة ما بعد التثبيت هي دالة منطقية تعمل تلقائيًا بعد تثبيت تطبيقك على مساحة عمل. ينفّذه الخادم بعد مزامنة البيانات الوصفية للتطبيق وإنشاء عميل SDK، بحيث تكون مساحة العمل جاهزة تمامًا للاستخدام ويكون المخطط الجديد مطبَّقًا. تشمل حالات الاستخدام النموذجية تهيئة البيانات الافتراضية، وإنشاء السجلات الأولية، وتكوين إعدادات مساحة العمل، أو توفير الموارد على خدمات جهات خارجية.يمكنك أيضًا تنفيذ دالة ما بعد التثبيت يدويًا في أي وقت باستخدام CLI:النقاط الرئيسية:
src/logic-functions/post-install.ts
- تستخدم دوال ما بعد التثبيت
definePostInstallLogicFunction()— وهو إصدار متخصص يستبعد إعدادات المُشغِّل (cronTriggerSettingsوdatabaseEventTriggerSettingsوhttpRouteTriggerSettingsوisTool). - يتلقى المعالج
InstallPayloadيحتوي على{ previousVersion?: string; newVersion: string }— حيث إنnewVersionهو الإصدار الجاري تثبيته، وpreviousVersionهو الإصدار الذي كان مُثبّتًا سابقًا (أوundefinedعند التثبيت الأولي). استخدم هذه القيم للتمييز بين عمليات التثبيت الجديدة والترقيات ولتشغيل منطق الترحيل الخاص بالإصدار. - موعد تشغيل الخطاف: في عمليات التثبيت الجديدة فقط، افتراضيًا. مرّر
shouldRunOnVersionUpgrade: trueإذا كنت تريد تشغيله أيضًا عند ترقية التطبيق من إصدار سابق. عند إغفاله، تكون القيمة الافتراضية للعلمfalse، وتتجاوز الترقيات هذا الخطاف. - نموذج التنفيذ — غير متزامن افتراضيًا، والتزامني اختياري: يتحكّم العلم
shouldRunSynchronouslyفي كيفية تنفيذ ما بعد التثبيت.shouldRunSynchronously: false(الإعداد الافتراضي) — يتم إدراج الخطاف في قائمة الرسائل معretryLimit: 3ويعمل بشكل غير متزامن داخل عامل عمل. يعود ردّ التثبيت بمجرد وضع المهمة في الطابور، لذا فإن معالجًا بطيئًا أو متعطلًا لا يحجب المستدعي. سيُجرِّب العامل إعادة المحاولة حتى ثلاث مرات. استخدم هذا للمهام طويلة التشغيل — بَذر مجموعات بيانات كبيرة، استدعاء واجهات برمجة تطبيقات خارجية بطيئة، تهيئة موارد خارجية، أو أي شيء قد يتجاوز نافذة استجابة HTTP المعقولة.shouldRunSynchronously: true— يُنفّذ الخطاف ضمن تدفّق التثبيت مباشرةً (نفس المنفِّذ كما قبل التثبيت). يَحجُب طلب التثبيت حتى ينتهي المعالج، وإذا رمى استثناءً، سيتلقى مستدعي التثبيتPOST_INSTALL_ERROR. لا توجد محاولات إعادة تلقائية. استخدم هذا للمهام السريعة التي يجب إكمالها قبل الاستجابة — مثل إظهار خطأ تحقق للمستخدم، أو إعداد سريع سيعتمد عليه العميل مباشرةً بعد عودة نداء التثبيت. ضع في اعتبارك أن ترحيل البيانات الوصفية يكون قد طُبِّق بالفعل عند تشغيل ما بعد التثبيت، لذلك فإن فشل الوضع المتزامن لا يعيد التغييرات على المخطط إلى الوراء — بل يكتفي بإبراز الخطأ.
- تأكّد من أن معالجك قابل للتنفيذ المتكرر دون آثار جانبية. في الوضع غير المتزامن قد تُعيد قائمة الانتظار المحاولة حتى ثلاث مرات؛ وفي أي من الوضعين قد يعمل الخطاف مجددًا أثناء الترقيات عند ضبط
shouldRunOnVersionUpgrade: true. - متغيرات البيئة
APPLICATION_IDوAPP_ACCESS_TOKENوAPI_URLمتاحة داخل المعالج (كما في أي دالة منطق أخرى)، لذا يمكنك استدعاء واجهة Twenty API باستخدام رمز وصول للتطبيق مقيّد بنطاق تطبيقك. - يُسمح بدالة ما بعد التثبيت واحدة فقط لكل تطبيق. سيُنتج إنشاء ملف البيان خطأً إذا تم اكتشاف أكثر من واحدة.
- تُرفَق خصائص الدالة
universalIdentifierوshouldRunOnVersionUpgradeوshouldRunSynchronouslyتلقائيًا ببيان التطبيق ضمن الحقلpostInstallLogicFunctionأثناء عملية البناء — ولا تحتاج إلى الإشارة إليها فيdefineApplication(). - تم تعيين مهلة افتراضية إلى 300 ثانية (5 دقائق) للسماح بمهام الإعداد الأطول مثل تهيئة البيانات.
- لا يُنفَّذ في وضع التطوير: عند تسجيل تطبيق محليًا (عبر
yarn twenty dev)، يتجاوز الخادم تدفّق التثبيت بالكامل ويُزامن الملفات مباشرةً عبر مراقِب CLI — لذا لن يعمل ما بعد التثبيت في وضع التطوير مطلقًا، بغضّ النظر عنshouldRunSynchronously. استخدمyarn twenty exec --postInstallلتشغيله يدويًا على مساحة عمل قيد التشغيل.
definePreInstallLogicFunction
تعريف دالة منطقية لما قبل التثبيت (واحدة لكل تطبيق)
definePreInstallLogicFunction
تعريف دالة منطقية لما قبل التثبيت (واحدة لكل تطبيق)
دالة ما قبل التثبيت هي دالة منطقية تعمل تلقائيًا أثناء التثبيت، قبل تطبيق ترحيل البيانات الوصفية لمساحة العمل. تتشارك نفس بنية الحمولة مع ما بعد التثبيت (يمكنك أيضًا تنفيذ دالة ما قبل التثبيت يدويًا في أي وقت باستخدام CLI:النقاط الرئيسية:
InstallPayload)، لكنها موضوعة أبكر في تدفّق التثبيت كي تجهّز حالة يعتمد عليها الترحيل القادم — ومن الاستخدامات الشائعة: نسخ البيانات احتياطيًا، التحقق من التوافق مع المخطط الجديد، أو أرشفة السجلات التي ستُعاد هيكلتها أو ستُحذف.src/logic-functions/pre-install.ts
- تستخدم دوال ما قبل التثبيت
definePreInstallLogicFunction()— نفس الإعدادات المتخصصة كما في ما بعد التثبيت، لكنها مرتبطة بموضع مختلف ضمن دورة الحياة. - يتلقّى كلٌّ من معالجي ما قبل التثبيت وما بعد التثبيت النوع نفسه
InstallPayload:{ previousVersion?: string; newVersion: string }. استورده مرة واحدة وأعد استخدامه لكلا الخطافين. - موعد تشغيل الخطاف: موضوع مباشرةً قبل ترحيل البيانات الوصفية لمساحة العمل (
synchronizeFromManifest). قبل التنفيذ، يُشغِّل الخادم مزامنة “pared-down sync” ذات طابع إضافي فقط تقوم بتسجيل دالة ما قبل التثبيت للإصدار الجديد في البيانات الوصفية لمساحة العمل — دون لمس أي شيء آخر — ثم يُنفّذها. لأن هذه المزامنة «إضافية فقط»، تبقى كائنات وحقول وبيانات الإصدار السابق سليمة عند تشغيل معالجك: يمكنك قراءة حالة ما قبل الترحيل ونسخها احتياطيًا بأمان. - نموذج التنفيذ: يُنفَّذ ما قبل التثبيت بشكل متزامن ويحجب عملية التثبيت. إذا رمى المعالج استثناءً، تُلغى عملية التثبيت قبل تطبيق أي تغييرات على المخطط — وتبقى مساحة العمل على الإصدار السابق بحالة متّسقة. هذا مقصود: ما قبل التثبيت هو فرصتك الأخيرة لرفض ترقية تنطوي على مخاطر.
- كما هو الحال مع ما بعد التثبيت، يُسمح بدالة ما قبل التثبيت واحدة فقط لكل تطبيق. تُربَط تلقائيًا ببيان التطبيق تحت
preInstallLogicFunctionأثناء عملية البناء. - لا يُنفَّذ في وضع التطوير: كما في ما بعد التثبيت — يتم تجاوز تدفّق التثبيت بالكامل للتطبيقات المسجّلة محليًا، لذا لن يعمل ما قبل التثبيت مطلقًا عند
yarn twenty dev. استخدمyarn twenty exec --preInstallلتشغيله يدويًا.
ما قبل التثبيت مقابل ما بعد التثبيت: متى تستخدم أيّهما
اختيار خطاف التثبيت المناسب
ما قبل التثبيت مقابل ما بعد التثبيت: متى تستخدم أيّهما
اختيار خطاف التثبيت المناسب
كلا الخطافين جزء من تدفّق التثبيت نفسه ويتلقّيان نفس ما قبل التثبيت دائمًا متزامن (يحجب التثبيت ويمكنه إحباطه). ما بعد التثبيت غير متزامن افتراضيًا — يُدرج على عامل مع محاولات إعادة تلقائية — لكن يمكن التبديل إلى تنفيذ متزامن عبر استخدم قاعدة عامة:
InstallPayload. الاختلاف يكمن في موعد تشغيلهما نسبةً إلى ترحيل البيانات الوصفية لمساحة العمل، وهذا يغيّر البيانات التي يمكنهما التعامل معها بأمان.shouldRunSynchronously: true. راجع الأكورديون definePostInstallLogicFunction أعلاه لمعرفة متى تستخدم كل وضع.استخدم post-install لأي شيء يتطلّب وجود المخطط الجديد. وهذا هو السيناريو الشائع:- بَذر بيانات افتراضية (إنشاء سجلات أولية وعروض افتراضية ومحتوى تجريبي) للكائنات والحقول المضافة حديثًا.
- تسجيل خطافات الويب مع خدمات أطراف ثالثة بعد أن حصل التطبيق على بيانات الاعتماد الخاصة به.
- استدعاء واجهة برمجة التطبيقات الخاصة بك لإكمال إعداد يعتمد على البيانات الوصفية المتزامنة.
- منطق idempotent لتحقيق “تأكّد من وجود هذا” والذي ينبغي مواءمة الحالة في كل ترقية — بالاقتران مع
shouldRunOnVersionUpgrade: true.
PostCard افتراضي بعد التثبيت:src/logic-functions/post-install.ts
pre-install عندما قد يُتلف الترحيل أو يدمّر البيانات الحالية. لأن ما قبل التثبيت يعمل مقابل المخطط السابق وفشله يُرجِع الترقية إلى الوراء، فهو المكان المناسب لأي شيء محفوف بالمخاطر:- نسخ البيانات احتياطيًا قبل حذفها أو إعادة هيكلتها — مثل إزالة حقل في v2 وتحتاج إلى نسخ قيمه إلى حقل آخر أو تصديرها إلى التخزين قبل تشغيل الترحيل.
- أرشفة السجلات التي سيبطلها قيد جديد — مثل أن يصبح حقل ما
NOT NULLوتحتاج أولًا إلى حذف الصفوف ذات القيم الفارغة أو إصلاحها. - التحقق من التوافق ورفض الترقية إذا تعذّر ترحيل البيانات الحالية بسلاسة — ارمِ من داخل المعالج وسيُلغى التثبيت دون تطبيق أي تغييرات. هذا أكثر أمانًا من اكتشاف عدم التوافق في منتصف الترحيل.
- إعادة تسمية البيانات أو إعادة تعيين مفاتيحها قبل تغيير في المخطط قد يؤدي إلى فقدان الارتباط.
src/logic-functions/pre-install.ts
| You want to… | استخدام |
|---|---|
| بذر بيانات افتراضية، تهيئة مساحة العمل، تسجيل موارد خارجية | post-install |
| تشغيل بذر طويل الأمد أو استدعاءات أطراف ثالثة لا ينبغي أن تحجب استجابة التثبيت | post-install (الإعداد الافتراضي — shouldRunSynchronously: false، مع محاولات إعادة من العامل) |
| تشغيل إعداد سريع سيعتمد عليه المستدعي مباشرةً بعد عودة نداء التثبيت | post-install مع shouldRunSynchronously: true |
| قراءة البيانات أو نسخها احتياطيًا والتي قد يفقدها الترحيل القادم | pre-install |
| رفض ترقية قد تُفسد البيانات الحالية | pre-install (ارمِ من المعالج) |
| تنفيذ مواءمة في كل ترقية | post-install مع shouldRunOnVersionUpgrade: true |
| تنفيذ إعداد لمرة واحدة في التثبيت الأول فقط | post-install مع shouldRunOnVersionUpgrade: false (الإعداد الافتراضي) |
إذا ساورك الشك، فاجعل الافتراضي هو post-install. الجأ إلى ما قبل التثبيت فقط عندما يكون الترحيل نفسه هدّامًا وتحتاج إلى التقاط الحالة السابقة قبل أن تزول.
عملاء واجهة برمجة تطبيقات مضبوطة الأنواع (twenty-client-sdk)
توفر حزمة twenty-client-sdk عميلين لـ GraphQL ذوي أنواع ثابتة للتفاعل مع واجهة Twenty البرمجية من وظائفك المنطقية ومكوّنات الواجهة الأمامية.
| العميل | استيراد | نقطة النهاية | مُولَّد؟ |
|---|---|---|---|
CoreApiClient | twenty-client-sdk/core | /graphql — بيانات مساحة العمل (السجلات، الكائنات) | نعم، في وقت التطوير/البناء |
MetadataApiClient | twenty-client-sdk/metadata | /metadata — تكوين مساحة العمل، رفع الملفات | لا، يأتي مُجهزًا مسبقًا |
CoreApiClient
استعلام وتعديل بيانات مساحة العمل (السجلات، الكائنات)
CoreApiClient
استعلام وتعديل بيانات مساحة العمل (السجلات، الكائنات)
CoreApiClient هو العميل الرئيسي للاستعلام وتعديل بيانات مساحة العمل. يُولَّد من مخطط مساحة العمل لديك أثناء yarn twenty dev أو yarn twenty build، لذا فهو مضبوط الأنواع بالكامل ليتوافق مع كائناتك وحقولك.true لتضمين حقل، واستخدم __args للوسيطات، وعشّش الكائنات للعلاقات. ستحصل على إكمال تلقائي كامل وفحص للأنواع يعتمد على مخطط مساحة العمل لديك.يتم توليد CoreApiClient في وقت التطوير/البناء. إذا استخدمته دون تشغيل
yarn twenty dev أو yarn twenty build أولًا، فسيؤدي ذلك إلى خطأ. تحدث عملية التوليد تلقائيًا — إذ يستطلع CLI مخطط GraphQL لمساحة عملك وينشئ عميلًا مضبوط الأنواع باستخدام @genql/cli.استخدام CoreSchema للتعليقات التوضيحية للأنواع
CoreSchema يوفّر أنواع TypeScript المطابقة لكائنات مساحة العمل لديك — مفيد لتعيين أنواع حالة المكوّن أو معاملات الدوال:MetadataApiClient
إعدادات مساحة العمل، والتطبيقات، ورفع الملفات
MetadataApiClient
إعدادات مساحة العمل، والتطبيقات، ورفع الملفات
يأتي
النقاط الرئيسية:
MetadataApiClient مُجهّزًا مسبقًا مع SDK (لا حاجة للتوليد). يستعلم عن نقطة النهاية /metadata للحصول على تكوين مساحة العمل والتطبيقات ورفع الملفات.رفع الملفات
يتضمنMetadataApiClient طريقة uploadFile لإرفاق الملفات بالحقول من نوع الملف:| المعلمة | النوع | الوصف |
|---|---|---|
fileBuffer | Buffer | المحتوى الخام للملف |
filename | string | اسم الملف (يُستخدم للتخزين والعرض) |
contentType | string | نوع MIME (القيمة الافتراضية application/octet-stream إذا لم يُحدَّد) |
fieldMetadataUniversalIdentifier | string | قيمة universalIdentifier لحقل نوع الملف في كائنك |
- يستخدم
universalIdentifierالخاص بالحقل (وليس معرّفه الخاص بمساحة العمل)، بحيث يعمل كود الرفع لديك عبر أي مساحة عمل مُثبَّت فيها تطبيقك. - العنوان
urlالمُعاد هو عنوان URL موقّع يمكنك استخدامه للوصول إلى الملف المرفوع.
عند تشغيل كودك على Twenty (وظائف منطقية أو مكوّنات أمامية)، يقوم النظام الأساسي بحقن بيانات الاعتماد كمتغيرات بيئية:
TWENTY_API_URL— عنوان URL الأساسي لواجهة Twenty البرمجيةTWENTY_APP_ACCESS_TOKEN— مفتاح قصير العمر ذو نطاق يقتصر على الدور الافتراضي لوظيفة تطبيقك
process.env. تُحدَّد أذونات مفتاح واجهة برمجة التطبيقات بواسطة الدور المشار إليه في defaultRoleUniversalIdentifier ضمن application-config.ts.