WebService على Navision / Microsoft Dynamics الإصدار 5 ... أو غير ذلك؟

Question

اذهب مكافأة!

لقد أكسبني هذا السؤال شارة Tumbleweed (7 وجهات نظر في 7 أيام!) ، وهو تأكيد قوي إلى حد ما على ذلك البحرية لديه حصة سوقية محدودة للغاية ، والتي - أظن أنه ينبغي أن تكون تأكيدا أن البحرية ليست كل هذا البرنامج الرائع ...

لكن مهلا ... هذا ما حصلنا عليه كأفراد خلفي ، لذلك أنا مستعد للقتال مع هذا. : -o

إذا كان هناك بعض مطور Navision الجريء الذي يمكنه إلقاء الضوء على هذا ... فإن المكافأة موجودة من أجلك! قون

---

المنشور الأصلي

لقد قمت مؤخرًا بتطبيق نظام تجارة إلكتروني معقد إلى حد ما يتفاعل مع نهاية قديمة على أساس NAVISION 5 لحوادث.

احتياجاتنا هي:

1. إلى فضح عناصر معينة من منطق العمل من كل منصة إلى أخرى (على سبيل المثال: "ما هو المبلغ الإجمالي الذي تم شراؤه من قبل هذا العميل؟" ، "ما هي المنتجات المعروضة حاليًا؟" ، "كم عدد العملاء الجدد الذين سجلوا على موقع الويب؟" ، إلخ. ..).
2. إلى لديها آليات للتغذية الخلفية / التحقق من الصحة بالنسبة للمعاملات المختلفة (على سبيل المثال: "إليك طلب جديد من العميل X" ... "حسنًا ، حصل عليه ، سيبدأ الآن في معالجته" ... "حسنًا ، انسخ ذلك ، وداعًا!").
3. اذا كان ممكنا، تجنب اللعب مع الملفات, ، ولكن الحفاظ على كل هذا يحدث من حيث المكالمات/المنافذ/الخدمات ...

الطريقة الأكثر طبيعية التي يمكن أن أفكر فيها هي دمج النظامين عبر WebService ، لكن Navision 5 لا يدعم ذلك أصليًا. لذلك فعلت "العناية الواجبة" ووجدت بعض الأشياء على MSDN بما في ذلك هذه المقالة و هذا الآخر.

وفقا لهذه المقالات لا ينبغي أن يكون من الصعب إنشاء خدمة ويب على Navision 5, ولكن عندما اقترحت هذا الحل للفريق المسؤول عن النظام القديم ، أخبرونا أنها "نظرية خالصة" ولا يعرفون أي شخص قام بتطبيقه على الإطلاق.

ليس لدي أي سبب للشك في كلمتهم ، ولكن الأميال يمكن أن تختلف... واعتقدت أنه ربما في مجتمع SO ، يوجد محترفون من بلدان أخرى قاموا بالفعل بتنفيذ شيء مشابه ويتوفرون لتبادل تجربتهم.

لذا ، سؤالي ذو طيبة:

1. هل هناك أي شخص لديه جربت هذا في المنزل وستكون متاحة للمشاركة قليلاً على ما كانت أكبر الصعوبات ، إذا كانت النتيجة النهائية موثوقة ، إذا اعتقدوا أن النتيجة تستحق الجهد ، إلخ ...؟
2. هل هناك أي شخص واجه مشكلة مماثلة ولكنه حلها بنهج مختلف وسيكون ذلك متاحًا لتقديم حله ("لم أفعل ذلك أبدًا ، لكن إذا اضطررت إلى فعل ذلك ، فسأفعل ذلك مثل هذا ..." من الإجابات موضع ترحيب أيضًا)؟

شكرا لك مقدما على وقتك! قون

Answer 1

أنا أيضًا سوف أتناغم مع إجابة مفيدة غير مفيدة حول NAV 6 :)

لقد أكملت للتو مشروعًا باستخدام NAV 6. بشكل مدهش ، من السهل جدًا فضح خدمات الويب والاستهلاك. إنها حقًا مسألة تافهة للعثور على كائن في واجهة WebServices ووضع علامة مربع لإخباره بفضح نفسه.

من غير المثير للدهشة ، لا تعمل خدمات الويب كما تتوقع ، يجب عليك في كثير من الأحيان استخدام بعض الأخطاء والخطأ في الحصول على كائنات وخصائص لاستمرارها ، لأنها حساسة حقًا لتسلسل الأحداث التي تستخدمها لحفظها وتهمةها. ويبدو أن كل كائن يعمل بشكل مختلف قليلاً. على سبيل المثال: لإنشاء عميل ، اكتشفت في النهاية أنه يتعين عليك إنشاء وحفظ عميل فارغ ، وقم بتدليك هذا السجل الجديد باستخدام CodeUnit ، ثم جلب السجل ثم كتابة سمات العميل وحفظها مرة أخرى. أنا مُتوقع لإنشاء عميل جديد () فقط ، قم بتعيين السمات وحفظه في ضربة سريعة واحدة.

أظن أنك لست حريصًا جدًا على الترقية إلى NAV6 ، ولكن خارج رأسي ، إليك كيفية محاكاة خدمات الويب:

يمكن أن تستهلك SharePoint بالفعل وفضح خدمات الويب ، بحيث لا تكون هذه المشكلة مشكلة. لا تملك NAV 5 "بشكل طبيعي" ، ولكن يمكنك طهي برنامجك الخاص الذي يعمل كخدمة "وسيط" ويب - ستحصل بالفعل على معلومات داخل وخارج NAV ، عبر XML في الغالب. يمكنك إنشاء هذا الوسيط لأخذ الإدخال كملفات XML وتدليكها لاستخدامها في مكالمة خدمة الويب. يمكنك حتى التخلي عن XML والكتابة والقراءة مباشرة من DB ، حيث يتم تخزين جميع معلومات NAV هناك على أي حال. إذن هذا ما أفكر فيه:

NAV <-> SQL Server <-> جديد "Broker" WebService <-> SharePoint

أو إذا كان لديك بالفعل API NAV Down PAT وترغب في استئناف XML الخاص بك:

NAV <-> ملفات XML <-> جديدة "Broker" WebService <-> SharePoint

إذا كنت تستخدم XML واستخدمت مراقبي Filewatch ، فلن يكون الكمون سيئًا للغاية ، وعادةً ما يلتقط مراقبو Filewathers انخفاضًا أو تغييرًا في المللي ثانية.

حسنًا ، لكني أعتقد أنك كذلك المحتمل من المفترض أن تستخدم biztalk لأشياء مثل هذا: NAV <-> biztalk <-> SharePoint

لكنني لا أعرف مدى سهولة إعداد BizTalk للتواصل مع NAV. أراهن أنه من المثير للغاية أن تعمل comms ، ولكن هذا هو تكهنات.

على أي حال ، لا أعرف مدى فائدة هذا المنشور ، لكن ربما يمنحك بعض الأفكار التي يجب الذهاب إليها.

هتاف ، لانس

Answer 2

حيث أعمل ، تمكنا من استخدام إحدى خدمات الويب من NAV 6 لتكاملها مع SharePoint ، حتى تتمكن من البحث عن عميل أو تسجيل وإظهاره في جزء ويب في SharePoint. أعلم أن سؤالك يدور حول NAV 5 على وجه الخصوص ، لكنني لم أر هذا العمل إلا على NAV 6. ولم أكن المطور الذي عمل على هذا ، لذلك ليس لدي المزيد من التفاصيل التي أخشى.

هل حاولت السؤال على mibuso.com؟ إنهم يركزون أكثر بكثير.

Answer 3

عندما تقول الكشف عن منطق العمل ، هل يشمل ذلك تنفيذ الرمز (مثل CodeUnit)؟ إذا كنت بحاجة فقط إلى إجراء استعلامات مقابل قاعدة البيانات ، فيمكنك استخدام NODBC & System.data.odbc أو CFRONT .NET API. يمكن بسهولة لف أي من هذه الأدوات باستخدام خدمة الويب .NET ، وكلاهما يدعم قاعدة بيانات NAV الأصلية. لتمرير الرسائل إلى الوراء ، لا تزال بحاجة إلى استخدام COM ، كما هو موضح في المقالة الأولى التي ذكرتها.

أي مما سبق ممكن تمامًا ، وسهل نسبيًا اعتمادًا على كفاءتك في .NET و COM و NAV.

المقالة الثانية التي ربطتها لوصف باستخدام NAS. أنا لست خبيراً في هذا ، لكنني أعتقد أن هذا قد يتطلب حبيبة ترخيص خاصة. قبل قضاء الوقت في تنفيذ أي شيء يستحق التحقق مما إذا كان ترخيصك يتضمن NAS أو CFRONT أو NODBC.

Answer 4

يمكنك بالفعل القيام "بالترقية الفنية" لـ NAV 5 إلى NAV 2009 ثم استخدام خدمات الويب الأصلية. بمعنى استبدال ملفات exe والتطبيق بأكمله (ولكن ليس الكائنات ، والتي ستظل الإصدار 5) ، واثنين من الحيل الأخرى. لكنه يعمل ، وبالتالي لديك عام 2009-Webservice-Functionality على NAV 5 :-)

Answer 5

لصالح أي شخص غوغلينغ هذا ، إذا كنت لا تزال في Navision 6 مع قاعدة البيانات الأصلية ، فإن طريقة جيدة لتوصيلها هي عبر قائمة انتظار الرسائل Windows.

يمكنك كتابة خدمة الويب الخاصة بك التي تضع طلبات XML في قائمة الانتظار ثم انتظر الرد على POP. على جانب Navision ، لديك عملاء واحد يسحب قائمة الانتظار ويضع الإجابات في قائمة انتظار الرد. هناك عميل خاص غير GUI يسمى NAS لذلك.

لقد كنت أستخدم هذا النهج لمدة 15 عامًا لربط محركات الحجز لخروج نهاية Navision. إنه يعمل بشكل جيد للغاية ولديه ميزة أنه يمكنك إلقاء نظرة خاطفة على الطلبات قبل الوصول إلى Navision ، حتى تتمكن من حماية نهايتك من العديد من الطلبات المعيبة.

المشكلة الوحيدة في هذا النهج هي أن أمر الالتزام داخل Navision باهظ الثمن. من الصعب تقديم كميات كبيرة من الطلبات. بمجرد أن تحتاج النهاية الخلفية إلى الالتزام ، فإنك تصل إلى عدد قليل من الطلبات في الثانية. قد يكون هذا جيدًا لحجم منخفض.

للحصول على حجم كبير ، تحتاج إلى تنفيذ التخزين المؤقت أو الحصول على بعض منطق العمل. بالنسبة لي ، تم ضرب مواقع مقارنة الأسعار ، لذلك هنا يخدم الحل تلك الموجودة في خدمات الويب المكتوبة في Python وتمرير الطلبات فقط إذا كان شخص ما يشتري شيئًا ما ...