ما هي أفضل استراتيجية للجمع بين الإنترانت وشبكة الويب المكشوفة؟

Question

كنت أتساءل ما إذا كان شخص ما لديه بعض البصيرة حول هذه المسألة.

خلفية صغيرة:

لقد كنا نستخدم القضبان للترحيل من نظام يستند إلى DBASE و Visual Basic قديم لبناء شركة داخلية داخلية تقوم بها أشياء مثل طباعة التسمية، والتحكم بالمخلاطة، والشحن، وما إلى ذلك - أساسا ERP

المعضلة

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

السؤال الفعلي

هل لدى أي شخص أي اقتراح حول كيفية إنجاز هذا بطريقة أفضل؟

فيما يلي ثلاثة خيارات أرى:

أ) قم ببناء تطبيق Rails منفصل على خادم ويب، سيتصل نفس DB أن التطبيق الداخلي لدينا يتصل به.

• +++ نجوم: البيانات الحية - نفس الشيء الذي ترى تطبيقاتنا الداخلية لدينا، أي أوامر إنشاء في الوقت الفعلي، يتم استنفاد المخزون على الفور

• --- ناقص: مخاطر أمنية محتملة، ازدواجية الكود - أي أحتاج إلى تكرار جميع وحدات التحكم أو النماذج والمناظر، وما إلى ذلك. هذا التعامل مع الطلبات.

ب) بناء تطبيق قضبان منفصل على خادم ويب، سيتصل ب مختلف DB من التطبيق الداخلي لدينا.

• +++ الإضافات: أقل التعرض الأمني.
• --- السلبيات: جهد إضافي لمزامنة DB و DB و DB الداخلية (أو استخدام خدمة ويب مثل Rest-API)، رمز إضافي لمعالجة استنفاد المخزون وإنشاء # إنشاء، ازدواجية الرمز - أي أحتاج إلى تكرار جميع وحدات التحكم، النماذج، وجهات النظر، وما إلى ذلك والتي تتعامل مع الطلبات.

ج) فضح التطبيق الداخلي على الويب

• +++ نجوم: جميع المشاكل من الأعلى القضاء عليها. هذا هو طريقة "جافة" كبيرة.
• --- ناقص: الكثير من الصداع الأمني. أنظمة تسجيل الدخول أكثر تعقيدا - واحد للويب والآخر للمستخدمين الداخليين باستخدام LDAP.

لذلك أي أفكار؟ أي شخص لديه مشكلة مماثلة للحل؟ يرجى مراعاة أن شركتنا لديها موارد محدودة - وهي مطور واحد مخصص لهذا. لذلك يجب أن يكون هذا أحد الحلول "الصحيحة" و "الذكية"، وليس "رمي الأموال / الأشخاص / الموارد في هذه الحلول.

شكرا لك.

Answer 1

ربما أقوم بإنشاء وحدات تحكم منفصلة للموقع العام واستخدام activeresource لسحب البيانات منك التطبيقات الداخلية. إلقاء نظرة على

http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1.html.

http://api.rubyonraina.org/classes/activeresource/base.html.

تحرير - ارتباط ثابت وأضاف رابط API

Answer 2

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

من المحتمل أن تكرر المستخدمين الداخليين البيانات كمستخدمين خارجيين.

Answer 3

من المحتمل أن تكون واجهة المستخدم العامة والموظفين الداخليين، الأمريكي، واجهة مستخدم مختلفة. يجب أن تكون البيانات متسقة لذلك أود أن أضع بعض الجهد لضمان وجود قاعدة بيانات واحدة نهائية تماما. لذلك: قاعدة بيانات واحدة اثنين من UIS؟

استمتع بطبقة "خدمة" أن كلا من UIS يمكن استخدامها. إذا كان هذا هو Java، فسوف أكون واثقا جدا من إجراء الخدمات بسرعة. أتساءل مدى سهولة في روبي / قضبان.

أفضل النتائج ستكون أن عميلك الحالي جافا واجهة المستخدم يمكن تكييفها لاستخدام طبقة خدمة القضبان.

Answer 4

على افتراض أنك تثق بالمبرمجين الخاص بك في عدم تعريض الأشياء بطريق الخطأ في المكان الخطأ، يبدو أن الحل "الصحيح" يبدو لي أن يكون لدي تطبيق واحد، ولكن مجموعتين مختلفتين من وحدات التحكم والمناظر، واحدة للاستخدام الداخلي، والآخر للمواجهة العامة. هذا سيمنحك فكرة DJNA عن قاعدة بيانات واحدة، واثنان من UIS.

كما تقول إن وجود قواعد بيانات منفصلة سيتضمن الكثير من الازدواجية، وكذلك مشكلة النسخ المتماثل.

لا معنى لي أن يكون لديك تطبيقان منفصلان تماما باستخدام نفس قاعدة البيانات؛ يعد جزء ACTIVERECORECORT من تطبيق Rails تجربة قاعدة البيانات في رمز Ruby، وبالتالي فإن وجود تجريدتين لقاعدة بيانات واحدة يبدو خاطئا بعض الشيء.

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

إذا كنت لا تثق تماما بالمبرمجين الخاص بك، فإن نهج Mike Activeresesource جيد جدا - فمن الصعب للغاية فضح الأشياء عن طريق الصدفة (على الرغم من أن activeresource هو أقل مرونة للغاية وميزة غنية من activerecord)

Answer 5

ما إصدار القضبان التي تستخدمها؟ نظرا لأنه يتم تضمين محركات القضبان الإصدار 2.3، فإن هذا يسمح بمشاركة التعليمات البرمجية المشتركة (النماذج / المشاهدات / وحدات التحكم) في مساعد القضبان.

انظر Railscast. للحصول على مقدمة قصيرة.

أنا استخدمها أيضا. لقد طورت ثلاثة تطبيقات لعملاء مختلفين، ولكن مع كل التعليمات البرمجية المشتركة في البرنامج المساعد.