قواعد التسمية في SAP CPI: حزمة قواعد يستطيع فريقك فرضها

لدى معظم فرق SAP Cloud Integration (SAP CPI) قواعد تسمية. لكن عددًا أقل منها لديه قواعد يلتزم بها كل iFlow، لأن القواعد تعيش في صفحة wiki ولا أحد يفحص اسم Content Modifier قبل النقل (transport).

يقترح هذا المقال قواعد أولية للخطوات والقنوات والخصائص والعناوين، ويبيّن كيف تكتبها في صورة قواعد تستطيع أداة فحصها، وكيف يتشاركها الفريق ويفرضها.

لماذا تهم الأسماء في SAP CPI

اسم الخطوة هو ما تراه عندما يتعطل شيء. فشاشة المراقبة تذكر الخطوة الفاشلة باسمها، والبحث عن "الخطوة التي تضبط معرّف الطلب" لا يجدها إلا إذا قال اسمها ذلك، ومستند التصميم أو التسليم يُقرأ كما تُقرأ تسميات الرسم. "Content Modifier 3" لا يقول شيئًا؛ أما CM_SetOrderHeaders فيقول ما يفعله.

والأسماء المتسقة تجعل iFlowين قابلين للمقارنة أيضًا: فالمراجع الذي يعرف القواعد يستطيع قراءة أي iFlow للفريق بنظرة واحدة.

قواعد أولية

بادئة لنوع الخطوة، ثم ما تفعله، بأسلوب PascalCase، تكفي معظم الفرق. هذه هي الحزمة التي يأتي بها Kitegra؛ وهي نقطة بداية للتكييف، وليست معيارًا من SAP:

اكتب قواعد التسمية في صورة قواعد قابلة للفحص

قواعد التسمية التي تستطيع أداة فحصها هي قائمة قواعد، واحدة لكل نوع من العناصر. النص الحرفي يجب أن يطابق تمامًا؛ و<Placeholder> يمثّل أي نص؛ و<PascalCase> و<camelCase> و<UPPER> و<lower> و<Number> تمثّل نصًا بذلك الشكل. وتنطبق أول قاعدة لكل نوع، ولكل قاعدة درجة خطورة: "خطأ" أو "تحذير" أو "معلومة".

في Kitegra تكون القواعد حزمة قواعد بصيغة JSON. وهذا مقتطف منها:

{
  "rules": [
    {
      "id": "content-modifier",
      "target": "content-modifier",
      "pattern": "CM_<Action>",
      "example": "CM_SetOrderHeaders",
      "notes": "Content Modifier: CM_ and what it sets.",
      "severity": "warning",
      "enabled": true
    },
    {
      "id": "mapping",
      "target": "mapping",
      "pattern": "MM_<Source>_to_<Target>",
      "example": "MM_Order_to_SalesOrder",
      "notes": "Message Mapping: source and target message.",
      "severity": "info",
      "enabled": true
    },
    {
      "id": "property",
      "target": "property",
      "pattern": "<camelCase>",
      "example": "orderId",
      "notes": "Exchange property names in camelCase.",
      "severity": "info",
      "enabled": true
    }
  ]
}

اتفقوا عليها كفريق

1. افتح صفحة الخيارات في الإضافة وابحث عن "قواعد التسمية". تبدأ بالحزمة الافتراضية.
2. غيّر "النمط" أو "الخطورة" أو "ملاحظات" لقاعدة ما، أو أوقف قاعدة بخيار "القاعدة مفعّلة"، أو اختر "إضافة قاعدة" وحدد ما "يفحص".
3. اختر "تصدير JSON" وضع الملف حيث يحتفظ الفريق بمعاييره، بجوار إرشادات النقل.
4. يختار كل زميل "استيراد JSON" مع ذلك الملف. وعندما يكون مسجّلًا الدخول عبر Posty5، ترافقه الحزمة بعد ذلك إلى كل جهاز.

تُبقي المزامنة حزمة الشخص الواحد متطابقة على كل أجهزته؛ أما ملف JSON المشترك فهو ما يُبقي الفريق على القواعد نفسها.

افحص iFlow وفق القواعد

افتح الـ iFlow، وانقر زر "Kitegra" واختر "الفاحص" (أو اضغط Alt+Shift+K). يسرد تبويب "التسمية" كل اسم مخالف للقواعد، مع عددها على الزر: الاسم الفعلي، و"المتوقع"، و"مثال"، وحيثما يسمح محتوى الخطوة، اسمًا في خانة "المقترح" مبنيًا على ما تفعله الخطوة. والنقر على نتيجة يحدد الخطوة على الرسم.

في وضع التعديل، يكتب "إعادة التسمية" الاسم المقترح في حقل Name للخطوة. ولا يحفظ أبدًا: تقول اللوحة "تمت إعادة التسمية. احفظ الـ iFlow للإبقاء عليها."، والقرار لك.

تظهر النتائج نفسها في تقرير الـ iFlow بجوار فحوص التصميم، كما تبيّن قائمة مراجعة الـ iFlow، والأسماء الجيدة تجعل مستند التصميم المُنشأ سهل القراءة.

كيف يساعدك Kitegra

التسمية جزء من iFlow Inspector في Kitegra. يقرأ الفحص نموذج الـ iFlow في متصفحك؛ وتُزامَن حزمة القواعد مع حساب Kitegra عند تسجيل الدخول، ولا يُرسل محتوى الـ iFlow أبدًا.

تحتسب كلٌّ من Helper وMessage Monitor وiFlow Inspector وiFlow Docs عدد iFlows التي تستخدمها عليها: 5 لكل وحدة بلا حساب، و50 في خطة Free، و100 في خطة Starter، و300 في خطة Pro، أما خطة Business فبلا حد. ويأتي Toolbox وميزات مساحة العمل الإضافية مجانًا. قارن بين الخطط.

جرّبها في الـ iFlow التالي

تعرّف على ما يضيفه Kitegra حول مصمم SAP Integration Suite، أو اطّلع عليه مع بقية وحدات Kitegra.

الأسئلة الشائعة