Integration Architecture for the Salesforce Platform : Part I

Describe the Enterprise Integration landscape and overall integration strategy, detailing associated risks, trade-offs, and business and technical considerations within a customer environment

thank for orginal article : https://developer.salesforce.com/blogs/developer-relations/2014/11/salesforce-integration-architecture.html

By Greg Cook | Published: November 26, 2014

เป็นการสรุปความเข้าใจของผมเองล้วนๆ ไม่มีใส่ไข่ครับ การเป็น good architecture ต้องมีความเข้าใจสถาปัตยกรรม (Architecture) และรูปแบบที่ดี (Pattern)

The Integration Architecture Aligns the Business Strategy with Technical Capabilities

การเป็น salesforce architecture ไม่ได้ขึ้นกับ เทคโนโลยี รูปแบบที่ตายตัว หรือการเมืองในบริษัท แต่ต้องดูถึงความต้องการของธุรกิจ roadmap แล้วค่อยเลือกสิ่งที่ salesforce สามารถตอบสนองความต้องการนั้นได้

The Integration Architecture supports a Mix of Batch Processing and Real-time Services Middleware

สำหรับคนที่ออกแบบระบบที่มีประสบการณ์ จะต้องผสมผสานการ integration ในรูปแบบของการประมวลผมแบบเยอะๆ (Batch) และ service-based pattern เช่น Rest , SOAP ที่เป็นแบบนี้เพราะ รูปแบบเดียวไม่สามารถตอบโจทย์ได้หมด เช่นมีงานที่ต้องทำ 1M Records คงยิง SOAP ไป salesforce จนบ้าเลย แบบนี้ก็ Batch API ดีกว่าครับ

The Integration Architecture is Based Upon Business Service Level Agreements (SLAs)

เรื่องของเวลาการส่งข้อมูล การพร้อมใช้ของข้อมูลนั้นก็สำคัญ SLA ต้องสามารถ support ความต้องการของ business ไม่อย่างนั้นเขาคงไม่ต้องการระบบห่วยๆหรอกครับกว่าจะได้ใช้ข้อมูล อีก2–3 วันบ้าไปแล้ว แล้วเกี่ยวอะไรล่ะ ก็เกี่ยวซิ เกี่ยวกับรูปแบบการ Process ว่าจะเป็นแบบ synchronous หรือ asynchronous จะทำเลย หรือ batch มัน หรือจะส่งไปทำที่ background process อย่าง @future job

The Integration Architecture Has a Clearly Defined Standard for Applying Different Integration Use Cases

จริงๆแล้วการทำ integration พอจะมีหลักเกณฑ์และรูปแบบที่ชัดเจนพอสมควรแล้วเพื่อเป็นแนวทางในการนำไปใช้

A Typical Enteprise Salesforce Integration Architecture

การทำ integration โดยส่วนใหญ่ก็ไม่พ้นรูปแบบตามภาพด้านล้างนี้ครับ

มาดูรูปแบบกันครับ

- Cloud-to-Ground (Salesforce Platform Originated)

รูปแบบนี้ถูกใช้เมื่อต้องการส่ง massage หรือ data จาก salesforce ไปที ระบบหลังบ้านเรา( On-Premise infrastructure)

Capability #1 : ส่วนนี้คือ message จะถูกส่ง จาก salesforce ไปที่ firewall หรือ reverse proxy ส่วนนี้ต้องคุยกับ network security ให้ดีจะเปิด firewall อะไร ดัก IP ก็ว่ากันไปเพราะเป็น Inbound จาก DMZ Zone เข้าไปที่ Intranet Zone จากที่ทำมาก็จะทำพวก Whitelisted IPs , One Way SSL, Two Way SSL , Basic Autheticate (UserName ,Password) ไรพวกนั้น

Capability #2 : จากนั้น message จะถูกส่งต่อไปที่ trusted On-Premise infrastructure โดยถ้าเป็นบริษัทที่มีระบบ ESB( middleware) มันก็จะทำการประสานงานต่่อเมื่อได้รับ message อยู่ที่ว่าจะทำอะไรต่อ เพราะ EBS มีการทำงานหลายรูปแบบ อาจจะมาจากค่าย IBM , MuleSoft ก็ว่าไป

Capability #3 : จาก EBS อาจจะส่งไปให้ SAO ต่ออีกก็ได้เพื่อไปทำ Business Process อะไรต่างๆ จากระบบที่มีอยู่แล้วก็ได้

Capability #4 : รูปแบบที่ Salesforce เข้ามาอ่าน data จาก Data WareHouse (DWH) หรือ Operation Data Store (ODS) เพื่อนำไปShow บนหน้า Salesforce ประมาณนั้น

more detail here : Integration Patterns and Practices

เดี๋ยวมาต่อ Part II นะครับ