การย้ายข้อมูลเดิมทำได้ยาก

หลายองค์กรมีระบบ CRM ทางธุรกิจในองค์กรที่เก่าและซับซ้อน วันนี้มีทางเลือก SaaS บนคลาวด์มากมายซึ่งมาพร้อมกับประโยชน์มากมาย จ่ายตามที่คุณไปและจ่ายเฉพาะสิ่งที่คุณใช้ ดังนั้นจึงตัดสินใจย้ายไปใช้ระบบใหม่

ไม่มีใครต้องการทิ้งข้อมูลที่มีค่าเกี่ยวกับลูกค้าไว้ในระบบเก่าและเริ่มต้นด้วยระบบใหม่ที่ว่างเปล่าดังนั้นเราจึงจำเป็นต้องย้ายข้อมูลนี้ น่าเสียดายที่การย้ายข้อมูลไม่ใช่เรื่องง่ายเช่นเดียวกับ ประมาณ 50 เปอร์เซ็นต์ของความพยายามในการปรับใช้ ถูกใช้โดยกิจกรรมการย้ายข้อมูล ตาม Gartner Salesforce เป็นผู้นำด้านโซลูชัน CRM บนคลาวด์ ดังนั้นการย้ายข้อมูลจึงเป็นหัวข้อหลักสำหรับการปรับใช้ Salesforce

อัปเกรดจาก python 2.7 เป็น 3.6

วิธีทำให้แน่ใจว่าการเปลี่ยนข้อมูลเดิมไปสู่ระบบใหม่ประสบความสำเร็จ
ในขณะที่รักษาประวัติศาสตร์ทั้งหมด ทวีต

ดังนั้นเราจะมั่นใจได้อย่างไรว่าการเปลี่ยนข้อมูลเดิมไปสู่ระบบใหม่ที่สดใสและมั่นใจว่าเราจะรักษาประวัติทั้งหมดไว้ ในบทความนี้ฉันมีเคล็ดลับ 10 ประการสำหรับการย้ายข้อมูลที่ประสบความสำเร็จ เคล็ดลับห้าข้อแรกใช้กับการย้ายข้อมูลโดยไม่คำนึงถึงเทคโนโลยีที่ใช้

การย้ายข้อมูลโดยทั่วไป

1. ทำการย้ายข้อมูลเป็นโครงการแยกต่างหาก

ในรายการตรวจสอบการปรับใช้ซอฟต์แวร์การย้ายข้อมูลไม่ใช่รายการ 'ส่งออกและนำเข้า' ที่จัดการโดยเครื่องมือย้ายข้อมูล 'กดปุ่มเดียว' ที่ชาญฉลาดซึ่งมีการทำแผนที่ที่กำหนดไว้ล่วงหน้าสำหรับระบบเป้าหมาย

การย้ายข้อมูลเป็นกิจกรรมที่ซับซ้อนสมควรได้รับโครงการแผนแนวทางงบประมาณและทีมแยกจากกัน ต้องสร้างขอบเขตและแผนระดับเอนทิตีเมื่อเริ่มต้นโครงการเพื่อให้มั่นใจว่าจะไม่มีเรื่องน่าประหลาดใจเช่น“ โอ้เราลืมโหลดรายงานการเยี่ยมชมของลูกค้าเหล่านั้นใครจะทำเช่นนั้น” สองสัปดาห์ก่อนกำหนด

แนวทางการย้ายข้อมูลกำหนดว่าเราจะโหลดข้อมูลในครั้งเดียวหรือไม่ (หรือที่เรียกว่า บิ๊กแบง ) หรือว่าเราจะโหลดแบทช์เล็ก ๆ ทุกสัปดาห์

นี่ไม่ใช่การตัดสินใจที่ง่าย แนวทางนี้ต้องได้รับการตกลงและสื่อสารกับผู้มีส่วนได้ส่วนเสียทางธุรกิจและทางเทคนิคทั้งหมดเพื่อให้ทุกคนทราบว่าข้อมูลจะปรากฏในระบบใหม่เมื่อใดและเมื่อใด สิ่งนี้ใช้กับระบบขัดข้องด้วย

2. ประมาณการตามความเป็นจริง

อย่าประเมินความซับซ้อนของการย้ายข้อมูลต่ำเกินไป งานที่ต้องใช้เวลามากมายมาพร้อมกับกระบวนการนี้ซึ่งอาจมองไม่เห็นเมื่อเริ่มต้นโครงการ

ตัวอย่างเช่นการโหลดชุดข้อมูลเฉพาะเพื่อวัตถุประสงค์ในการฝึกอบรมโดยมีข้อมูลที่เป็นจริงจำนวนมาก แต่มีรายการที่ละเอียดอ่อนทำให้กิจกรรมการฝึกอบรมไม่สร้างการแจ้งเตือนทางอีเมลให้กับลูกค้า

ปัจจัยพื้นฐานสำหรับการประมาณคือจำนวนฟิลด์ที่จะโอนจากระบบต้นทางไปยังระบบเป้าหมาย

จำเป็นต้องใช้เวลาจำนวนหนึ่งในขั้นตอนต่างๆของโครงการสำหรับทุกฟิลด์รวมถึงการทำความเข้าใจฟิลด์การแมปฟิลด์ต้นทางกับฟิลด์เป้าหมายการกำหนดค่าหรือการสร้างการเปลี่ยนแปลงดำเนินการทดสอบการวัดคุณภาพของข้อมูลสำหรับฟิลด์และอื่น ๆ

การใช้เครื่องมือที่ชาญฉลาดเช่น Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas และอื่น ๆ จะช่วยลดเวลานี้ได้โดยเฉพาะในขั้นตอนการสร้าง

โดยเฉพาะอย่างยิ่งการทำความเข้าใจแหล่งข้อมูลซึ่งเป็นงานที่สำคัญที่สุดในโครงการโยกย้ายใด ๆ - ไม่สามารถทำได้โดยอัตโนมัติด้วยเครื่องมือ แต่นักวิเคราะห์ต้องใช้เวลาในการดูรายการฟิลด์ทีละช่อง

ค่าประมาณที่ง่ายที่สุดของความพยายามโดยรวมคือวันละหนึ่งคนสำหรับทุกเขตข้อมูลที่ถ่ายโอนจากระบบเดิม

ข้อยกเว้นคือการจำลองข้อมูลระหว่างซอร์สเดียวกันและสคีมาเป้าหมายโดยไม่มีการแปลงเพิ่มเติม - บางครั้งเรียกว่าการโอนย้ายแบบ 1: 1 ซึ่งเราสามารถอิงค่าประมาณจากจำนวนตารางที่จะคัดลอกได้

การประมาณโดยละเอียดเป็นศิลปะของตัวเอง

3. ตรวจสอบคุณภาพข้อมูล

อย่าประเมินคุณภาพของแหล่งข้อมูลสูงเกินไปแม้ว่าจะไม่มีการรายงานปัญหาคุณภาพของข้อมูลจากระบบเดิมก็ตาม

ระบบใหม่มีกฎใหม่ซึ่งอาจละเมิดข้อมูลเดิม นี่คือตัวอย่างง่ายๆ อีเมลติดต่อสามารถบังคับได้ในระบบใหม่ แต่ระบบเดิมอายุ 20 ปีอาจมีมุมมองที่แตกต่างออกไป

อาจมีทุ่นระเบิดซ่อนอยู่ในข้อมูลประวัติที่ไม่ได้สัมผัสมาเป็นเวลานาน แต่สามารถเปิดใช้งานได้เมื่อถ่ายโอนไปยังระบบใหม่ ตัวอย่างเช่นข้อมูลเก่าที่ใช้สกุลเงินยุโรปซึ่งไม่มีอยู่แล้วจำเป็นต้องแปลงเป็นยูโรมิฉะนั้นจะต้องเพิ่มสกุลเงินในระบบใหม่

คุณภาพของข้อมูลมีอิทธิพลอย่างมากต่อความพยายามและกฎง่ายๆก็คือยิ่งเราก้าวไปไกลในประวัติศาสตร์เราก็จะค้นพบความยุ่งเหยิงมากขึ้น ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องตัดสินใจ แต่เนิ่นๆว่าจะทำอย่างไร มาก ประวัติที่เราต้องการโอนเข้าสู่ระบบใหม่

4. ดึงดูดนักธุรกิจ

นักธุรกิจเป็นเพียงคนเดียวที่เข้าใจข้อมูลอย่างแท้จริงและเป็นผู้ที่สามารถตัดสินใจได้ว่าจะทิ้งข้อมูลใดได้บ้างและจะเก็บข้อมูลใดไว้

เป็นสิ่งสำคัญที่จะต้องมีใครสักคนจากทีมธุรกิจที่เกี่ยวข้องในระหว่างการฝึกทำแผนที่และสำหรับการติดตามย้อนหลังในอนาคตการบันทึกการตัดสินใจในการทำแผนที่และเหตุผลของพวกเขาจะเป็นประโยชน์

เนื่องจากรูปภาพมีค่ามากกว่าหนึ่งพันคำให้โหลดชุดทดสอบลงในระบบใหม่และปล่อยให้ทีมธุรกิจเล่นด้วย

แม้ว่าการทำแผนที่การย้ายข้อมูลจะได้รับการตรวจสอบและอนุมัติโดยทีมธุรกิจ แต่ความประหลาดใจก็อาจปรากฏขึ้นเมื่อข้อมูลปรากฏใน UI ของระบบใหม่

“ โอ้ตอนนี้ฉันเข้าใจแล้วว่าเราต้องเปลี่ยนมันสักหน่อย” กลายเป็นวลีทั่วไป

การไม่ได้มีส่วนร่วมกับผู้เชี่ยวชาญเฉพาะเรื่องซึ่งมักจะเป็นคนที่มีงานยุ่งมากเป็นสาเหตุของปัญหาที่พบบ่อยที่สุดหลังจากที่ระบบใหม่เริ่มใช้งานจริง

windows 7 เขียนด้วยภาษาอะไร

5. มุ่งสู่โซลูชันการย้ายข้อมูลอัตโนมัติ

การย้ายข้อมูลมักถูกมองว่าเป็นกิจกรรมเพียงครั้งเดียวและ นักพัฒนา มักจะจบลงด้วยโซลูชันที่เต็มไปด้วยการดำเนินการโดยเจ้าหน้าที่โดยหวังว่าจะดำเนินการได้เพียงครั้งเดียว แต่มีหลายเหตุผลที่ควรหลีกเลี่ยงแนวทางดังกล่าว

• หากการย้ายข้อมูลแบ่งออกเป็นหลาย ๆ คลื่นเราจะต้องดำเนินการแบบเดิมซ้ำหลาย ๆ ครั้ง
• โดยปกติแล้วจะมีการย้ายข้อมูลอย่างน้อยสามครั้งสำหรับทุก wave: การทดสอบแบบแห้งเพื่อทดสอบประสิทธิภาพและฟังก์ชันการทำงานของการย้ายข้อมูลโหลดการตรวจสอบความถูกต้องของข้อมูลทั้งหมดเพื่อทดสอบชุดข้อมูลทั้งหมดและทำการทดสอบทางธุรกิจและแน่นอนภาระการผลิต จำนวนการรันเพิ่มขึ้นตามคุณภาพข้อมูลที่ไม่ดี การปรับปรุงคุณภาพข้อมูลเป็นกระบวนการที่ทำซ้ำดังนั้นเราจึงต้องมีการทำซ้ำหลาย ๆ ครั้งเพื่อให้ได้อัตราส่วนความสำเร็จที่ต้องการ

ดังนั้นแม้ว่าการย้ายข้อมูลจะเป็นกิจกรรมที่เกิดขึ้นเพียงครั้งเดียว แต่การดำเนินการโดยเจ้าหน้าที่จะทำให้การดำเนินการของคุณช้าลงอย่างมาก

การย้ายข้อมูล Salesforce

ต่อไปเราจะพูดถึงเคล็ดลับห้าประการสำหรับการโยกย้าย Salesforce ที่ประสบความสำเร็จ โปรดทราบว่าเคล็ดลับเหล่านี้น่าจะใช้ได้กับโซลูชันระบบคลาวด์อื่น ๆ เช่นกัน

6. เตรียมพร้อมสำหรับการโหลดที่ยาว

ประสิทธิภาพเป็นหนึ่งในการแลกเปลี่ยนที่ใหญ่ที่สุดหากไม่ได้รับการยกเว้นเมื่อเปลี่ยนจากโซลูชันในองค์กรไปเป็นโซลูชันระบบคลาวด์ - Salesforce ไม่ได้รับการยกเว้น

ระบบภายในองค์กรมักจะอนุญาตให้โหลดข้อมูลโดยตรงลงในฐานข้อมูลพื้นฐานและด้วยฮาร์ดแวร์ที่ดีเราสามารถเข้าถึงบันทึกหลายล้านรายการต่อชั่วโมงได้อย่างง่ายดาย

แต่ไม่ใช่ในระบบคลาวด์ ในระบบคลาวด์เราถูก จำกัด อย่างมากด้วยปัจจัยหลายประการ

• เวลาแฝงของเครือข่าย - ข้อมูลจะถูกถ่ายโอนผ่านอินเทอร์เน็ต
• เลเยอร์แอปพลิเคชัน Salesforce - ข้อมูลถูกเคลื่อนย้ายผ่านส่วนหนา API หลายชั้นหลายชั้น จนกว่าพวกเขาจะเข้าสู่ฐานข้อมูล Oracle
• โค้ดที่กำหนดเองใน Salesforce - การตรวจสอบความถูกต้องทริกเกอร์เวิร์กโฟลว์กฎการตรวจจับการทำซ้ำและอื่น ๆ ซึ่งส่วนใหญ่จะปิดใช้งานการโหลดแบบขนานหรือจำนวนมาก

ด้วยเหตุนี้ประสิทธิภาพการโหลดอาจเป็นหลายพันบัญชีต่อชั่วโมง

อาจน้อยกว่าหรืออาจมากกว่าขึ้นอยู่กับสิ่งต่างๆเช่นจำนวนฟิลด์การตรวจสอบความถูกต้องและทริกเกอร์ แต่มันช้ากว่าการโหลดฐานข้อมูลโดยตรงหลายเกรด

ต้องพิจารณาการลดประสิทธิภาพซึ่งขึ้นอยู่กับปริมาณข้อมูลใน Salesforce ด้วย

เกิดจากดัชนีใน RDBMS (Oracle) ที่ใช้สำหรับการตรวจสอบคีย์ต่างประเทศฟิลด์เฉพาะและการประเมินกฎการทำซ้ำ สูตรพื้นฐานคือการชะลอตัวประมาณ 50 เปอร์เซ็นต์สำหรับทุกเกรด 10 ซึ่งเกิดจาก O (logN) ส่วนความซับซ้อนของเวลาในการเรียงลำดับและการดำเนินการ B-tree

vr/ar/mr

ยิ่งไปกว่านั้น Salesforce ยังมีขีด จำกัด การใช้ทรัพยากรมากมาย

หนึ่งในนั้นคือ กำหนดขีด จำกัด API จำนวนมาก เป็น 5,000 แบทช์ในหน้าต่างบานเลื่อนตลอด 24 ชั่วโมงโดยสูงสุด 10,000 รายการในแต่ละชุด

ดังนั้นสูงสุดตามทฤษฎีคือ 50 ล้านบันทึกที่โหลดใน 24 ชั่วโมง

ในโปรเจ็กต์จริงค่าสูงสุดจะต่ำกว่ามากเนื่องจากขนาดแบตช์ที่ จำกัด เมื่อใช้เช่นทริกเกอร์ที่กำหนดเอง

สิ่งนี้มีผลกระทบอย่างมากต่อแนวทางการย้ายข้อมูล

แม้แต่ชุดข้อมูลขนาดกลาง (ตั้งแต่ 100,000 ถึง 1 ล้านบัญชี) แนวทางของบิ๊กแบงก็ไม่เป็นปัญหาดังนั้นเราจึงต้องแยกข้อมูลออกเป็นคลื่นการย้ายข้อมูลขนาดเล็ก

แน่นอนว่าสิ่งนี้ส่งผลกระทบต่อกระบวนการปรับใช้ทั้งหมดและเพิ่มความซับซ้อนในการย้ายข้อมูลเนื่องจากเราจะเพิ่มการเพิ่มข้อมูลลงในระบบที่มีการย้ายข้อมูลก่อนหน้านี้และข้อมูลที่ป้อนโดยผู้ใช้

เราต้องพิจารณาข้อมูลที่มีอยู่นี้ในการแปลงและการตรวจสอบความถูกต้อง

นอกจากนี้การโหลดที่ยาวนานอาจหมายความว่าเราไม่สามารถทำการย้ายข้อมูลได้ในระหว่างที่ระบบหยุดทำงาน

หากผู้ใช้ทั้งหมดอยู่ในประเทศเดียวเราสามารถใช้ประโยชน์จากไฟดับแปดชั่วโมงในช่วงกลางคืนได้

แต่สำหรับ บริษัท เช่น Coca-Cola ที่มีการดำเนินงานทั่วโลกนั้นเป็นไปไม่ได้ เมื่อเรามีสหรัฐอเมริกาญี่ปุ่นและยุโรปในระบบเราจะขยายเขตเวลาทั้งหมดดังนั้นวันเสาร์จึงเป็นตัวเลือกเดียวที่จะหยุดทำงานที่ไม่ส่งผลกระทบต่อผู้ใช้

และนั่นอาจไม่เพียงพอดังนั้นเราต้องโหลด ขณะออนไลน์ เมื่อผู้ใช้ทำงานกับระบบ

7. เคารพความต้องการในการย้ายข้อมูลในการพัฒนาแอปพลิเคชัน

ส่วนประกอบของแอปพลิเคชันเช่นการตรวจสอบความถูกต้องและทริกเกอร์ควรสามารถจัดการกับกิจกรรมการย้ายข้อมูลได้ การปิดใช้งานการตรวจสอบความถูกต้องอย่างหนักในขณะที่โหลดการย้ายข้อมูลไม่ใช่ทางเลือกหากระบบต้องออนไลน์ แต่เราต้องใช้ตรรกะที่แตกต่างกันในการตรวจสอบการเปลี่ยนแปลงที่ดำเนินการโดยผู้ใช้การย้ายข้อมูล

• ไม่ควรเปรียบเทียบฟิลด์วันที่กับวันที่จริงของระบบเนื่องจากจะปิดใช้งานการโหลดข้อมูลประวัติ ตัวอย่างเช่นการตรวจสอบต้องอนุญาตให้ป้อนวันที่เริ่มต้นของบัญชีที่ผ่านมาสำหรับข้อมูลที่ย้ายข้อมูล
• ฟิลด์บังคับซึ่งอาจไม่ได้รับการเติมข้อมูลในอดีตจะต้องถูกนำไปใช้โดยไม่บังคับ แต่ด้วยการตรวจสอบความถูกต้องที่ไวต่อผู้ใช้จึงอนุญาตให้มีค่าว่างสำหรับข้อมูลที่มาจากการย้ายข้อมูล แต่จะปฏิเสธค่าว่างที่มาจากผู้ใช้ทั่วไปผ่าน GUI .
• ทริกเกอร์โดยเฉพาะอย่างยิ่งทริกเกอร์ที่ส่งเร็กคอร์ดใหม่ไปยังการผสานรวมจะต้องสามารถเปิด / ปิดสำหรับผู้ใช้ที่ย้ายข้อมูลเพื่อป้องกันการรวมกับข้อมูลที่โอนย้าย

เคล็ดลับอีกประการหนึ่งคือการใช้รหัสเดิมของช่องหรือรหัสการย้ายข้อมูลในทุกออบเจ็กต์ที่ย้ายข้อมูล มีสองเหตุผลสำหรับเรื่องนี้ สิ่งแรกที่ชัดเจนคือเพื่อให้ ID จากระบบเก่าสำหรับการย้อนกลับ หลังจากข้อมูลอยู่ในระบบใหม่ผู้คนอาจยังต้องการค้นหาบัญชีของตนโดยใช้รหัสเก่าซึ่งพบได้ในที่ต่างๆเช่นอีเมลเอกสารและระบบติดตามข้อบกพร่อง นิสัยที่ไม่ดี? อาจจะ. แต่ผู้ใช้จะขอบคุณหากคุณเก็บรักษา ID เก่าไว้ เหตุผลประการที่สองคือด้านเทคนิคและมาจากข้อเท็จจริงที่ว่า Salesforce ไม่ยอมรับ ID ที่ระบุไว้อย่างชัดเจนสำหรับเรกคอร์ดใหม่ (ไม่เหมือนกับ Microsoft Dynamics) แต่สร้างขึ้นในระหว่างการโหลด ปัญหาเกิดขึ้นเมื่อเราต้องการโหลดอ็อบเจ็กต์ลูกเนื่องจากเราต้องกำหนด ID ของอ็อบเจ็กต์หลัก เนื่องจากเราจะทราบ ID เหล่านั้นหลังจากโหลดเท่านั้นนี่จึงเป็นการออกกำลังกายที่ไร้ประโยชน์

มาใช้บัญชีและที่อยู่ติดต่อของพวกเขาเช่น

1. สร้างข้อมูลสำหรับบัญชี
2. โหลดบัญชีลงใน Salesforce และรับรหัสที่สร้างขึ้น
3. รวมรหัสบัญชีใหม่ในข้อมูลติดต่อ
4. สร้างข้อมูลสำหรับผู้ติดต่อ
5. โหลดผู้ติดต่อใน Salesforce

เราสามารถทำได้ง่ายขึ้นโดยการโหลดบัญชีที่มีรหัสเดิมที่เก็บไว้ในช่องพิเศษภายนอก ช่องนี้สามารถใช้เป็นข้อมูลอ้างอิงของผู้ปกครองได้ดังนั้นเมื่อโหลดผู้ติดต่อเราเพียงแค่ใช้ Account Legacy ID เป็นตัวชี้ไปยังบัญชีหลัก:

1. สร้างข้อมูลสำหรับบัญชีรวมถึงรหัสเดิม
2. สร้างข้อมูลสำหรับผู้ติดต่อรวมถึงรหัสเดิมของบัญชี
3. โหลดบัญชีใน Salesforce
4. โหลดผู้ติดต่อใน Salesforce โดยใช้ Account Legacy ID เป็นข้อมูลอ้างอิงระดับบนสุด

สิ่งที่ดีที่นี่คือเราได้แยกรุ่นและเฟสการโหลดซึ่งช่วยให้สามารถขนานกันได้ดีขึ้นลดเวลาดับและอื่น ๆ

8. ระวังคุณลักษณะเฉพาะของ Salesforce

เช่นเดียวกับระบบใด ๆ Salesforce มีส่วนที่ยุ่งยากมากมายซึ่งเราควรทราบเพื่อหลีกเลี่ยงความประหลาดใจที่ไม่พึงประสงค์ในระหว่างการย้ายข้อมูล นี่คือตัวอย่างจำนวนหนึ่ง:

• การเปลี่ยนแปลงบางอย่างเกี่ยวกับผู้ใช้ที่ใช้งานอยู่จะสร้างการแจ้งเตือนทางอีเมลไปยังอีเมลของผู้ใช้โดยอัตโนมัติ ดังนั้นหากเราต้องการเล่นกับข้อมูลผู้ใช้เราจำเป็นต้องปิดการใช้งานผู้ใช้ก่อนและเปิดใช้งานหลังจากการเปลี่ยนแปลงเสร็จสิ้น ในสภาพแวดล้อมการทดสอบเราแย่งชิงอีเมลของผู้ใช้เพื่อไม่ให้การแจ้งเตือนเริ่มทำงานเลย เนื่องจากผู้ใช้ที่ใช้งานอยู่ใช้ใบอนุญาตที่มีราคาแพงเราจึงไม่สามารถให้ผู้ใช้ทุกคนใช้งานได้ในสภาพแวดล้อมการทดสอบทั้งหมด เราต้องจัดการชุดย่อยของผู้ใช้ที่ใช้งานอยู่ตัวอย่างเช่นเพื่อเปิดใช้งานเฉพาะผู้ที่อยู่ในสภาพแวดล้อมการฝึกอบรม
• ผู้ใช้ที่ไม่ได้ใช้งานสำหรับอ็อบเจ็กต์มาตรฐานบางอย่างเช่นบัญชีหรือเคสสามารถกำหนดได้หลังจากให้สิทธิ์ระบบ“ อัปเดตเรกคอร์ดกับเจ้าของที่ไม่ใช้งาน” เท่านั้น แต่สามารถกำหนดให้กับผู้ติดต่อและอ็อบเจ็กต์ที่กำหนดเองทั้งหมดได้เช่นกัน
• เมื่อผู้ติดต่อถูกปิดใช้งานช่องการเลือกไม่ใช้ทั้งหมดจะเปิดอยู่โดยเงียบ
• เมื่อโหลดสมาชิกทีมบัญชีที่ซ้ำกันหรือออบเจ็กต์การแชร์บัญชีบันทึกที่มีอยู่จะถูกเขียนทับโดยไม่โต้ตอบ อย่างไรก็ตามเมื่อโหลดคู่ค้าที่มีโอกาสซ้ำกันระบบจะเพิ่มเรกคอร์ดซึ่งทำให้เกิดรายการซ้ำ
• ช่องระบบเช่น Created Date, Created By ID, Last Modified Date, Last Modified By ID สามารถเขียนอย่างชัดเจนได้หลังจากให้สิทธิ์ระบบใหม่เท่านั้น 'ตั้งค่าฟิลด์การตรวจสอบเมื่อสร้างเรกคอร์ด'
• ไม่สามารถย้ายการเปลี่ยนแปลงค่า History-of-field ได้เลย
• ไม่สามารถระบุเจ้าของบทความความรู้ในระหว่างการโหลด แต่สามารถอัปเดตได้ในภายหลัง
• ส่วนที่ยุ่งยากคือการจัดเก็บเนื้อหา (เอกสารไฟล์แนบ) ไว้ใน Salesforce มีหลายวิธีในการดำเนินการ (โดยใช้ไฟล์แนบไฟล์แนบฟีดเอกสาร) และแต่ละวิธีมีข้อดีข้อเสียรวมถึงขีด จำกัด ขนาดไฟล์ที่แตกต่างกัน
• ช่องรายการเลือกบังคับให้ผู้ใช้เลือกค่าใดค่าหนึ่งที่อนุญาตเช่นประเภทบัญชี แต่เมื่อโหลดข้อมูลโดยใช้ Salesforce API (หรือเครื่องมือใด ๆ ที่สร้างขึ้นเช่น Apex Data Loader หรือ ตัวเชื่อมต่อ Informatica Salesforce ), ใด ๆ มูลค่าจะผ่านไป

รายการจะดำเนินต่อไป แต่สิ่งที่สำคัญที่สุดคือทำความคุ้นเคยกับระบบและเรียนรู้ว่ามันทำอะไรได้บ้างและทำอะไรไม่ได้ก่อนที่คุณจะตั้งสมมติฐาน อย่าถือว่าพฤติกรรมมาตรฐานโดยเฉพาะอย่างยิ่งสำหรับวัตถุหลัก ค้นคว้าและทดสอบอยู่เสมอ

9. อย่าใช้ Salesforce เป็นแพลตฟอร์มการย้ายข้อมูล

เป็นเรื่องที่น่าดึงดูดมากที่จะใช้ Salesforce เป็นแพลตฟอร์มสำหรับสร้างโซลูชันการย้ายข้อมูลโดยเฉพาะสำหรับนักพัฒนา Salesforce เป็นเทคโนโลยีเดียวกันสำหรับโซลูชันการย้ายข้อมูลสำหรับการปรับแต่งแอปพลิเคชัน Salesforce GUI เดียวกันเหมือนกัน ภาษาโปรแกรมเอเพ็กซ์ โครงสร้างพื้นฐานเดียวกัน Salesforce มีวัตถุที่สามารถทำหน้าที่เป็นตารางและภาษา SQL ชนิดหนึ่ง Salesforce Object Query Language (SOQL) . อย่างไรก็ตามโปรดอย่าใช้มัน มันจะเป็นข้อบกพร่องพื้นฐานทางสถาปัตยกรรม

Salesforce เป็นแอปพลิเคชั่น SaaS ที่ยอดเยี่ยมพร้อมคุณสมบัติดีๆมากมายเช่นการทำงานร่วมกันขั้นสูงและการปรับแต่งที่หลากหลาย แต่การประมวลผลข้อมูลจำนวนมากไม่ใช่หนึ่งในนั้น เหตุผลที่สำคัญที่สุดสามประการคือ:

• ประสิทธิภาพ - การประมวลผลข้อมูลใน Salesforce ช้ากว่าใน RDBMS หลายเกรด
• ขาดคุณสมบัติในการวิเคราะห์ - Salesforce SOQL ไม่รองรับการสืบค้นที่ซับซ้อนและฟังก์ชันการวิเคราะห์ที่ต้องรองรับโดยภาษา Apex และจะทำให้ประสิทธิภาพลดลงมากขึ้น
• สถาปัตยกรรม * - การวางแพลตฟอร์มการย้ายข้อมูลภายในสภาพแวดล้อมของ Salesforce นั้นไม่สะดวกมากนัก โดยปกติแล้วเรามีสภาพแวดล้อมที่หลากหลายสำหรับวัตถุประสงค์เฉพาะซึ่งมักสร้างขึ้นเฉพาะกิจเพื่อให้เราสามารถใช้เวลาในการซิงโครไนซ์โค้ดได้มาก นอกจากนี้คุณยังต้องพึ่งพาการเชื่อมต่อและความพร้อมใช้งานของสภาพแวดล้อม Salesforce นั้น ๆ

ให้สร้างโซลูชันการย้ายข้อมูลในอินสแตนซ์แยกต่างหาก (อาจเป็นระบบคลาวด์หรือในองค์กร) โดยใช้แพลตฟอร์ม RDBMS หรือ ETL เชื่อมต่อกับระบบต้นทางและกำหนดเป้าหมายสภาพแวดล้อม Salesforce ที่คุณต้องการย้ายข้อมูลที่คุณต้องการไปยังพื้นที่จัดเตรียมของคุณและประมวลผลที่นั่น สิ่งนี้จะช่วยให้คุณ:

• ใช้ประโยชน์จากพลังและความสามารถทั้งหมดของภาษา SQL หรือคุณสมบัติ ETL
• มีรหัสและข้อมูลทั้งหมดในที่เดียวเพื่อให้คุณสามารถเรียกใช้การวิเคราะห์ในทุกระบบ
  • ตัวอย่างเช่นคุณสามารถรวมการกำหนดค่าใหม่ล่าสุดจากสภาพแวดล้อม Salesforce ทดสอบล่าสุดกับข้อมูลจริงจากสภาพแวดล้อม Salesforce ที่ใช้งานจริง
• คุณไม่ได้พึ่งพาเทคโนโลยีของระบบต้นทางและระบบเป้าหมายมากนักและคุณสามารถใช้โซลูชันของคุณซ้ำสำหรับโครงการถัดไปได้

10. การกำกับดูแลข้อมูลเมตาของ Salesforce

ในช่วงเริ่มต้นโครงการเรามักจะคว้ารายการฟิลด์ Salesforce และเริ่มแบบฝึกหัดการทำแผนที่ ในระหว่างโครงการมักเกิดขึ้นที่ทีมพัฒนาแอปพลิเคชันเพิ่มฟิลด์ใหม่ลงใน Salesforce หรือมีการเปลี่ยนแปลงคุณสมบัติของฟิลด์บางอย่าง เราสามารถขอให้ทีมแอปพลิเคชันแจ้งทีมย้ายข้อมูลเกี่ยวกับการเปลี่ยนแปลงโมเดลข้อมูลทุกครั้ง แต่ก็ไม่ได้ผลเสมอไป เพื่อความปลอดภัยเราจำเป็นต้องมีการเปลี่ยนแปลงรูปแบบข้อมูลทั้งหมดภายใต้การดูแล

วิธีทั่วไปในการทำเช่นนี้คือการดาวน์โหลดข้อมูลเมตาที่เกี่ยวข้องกับการย้ายข้อมูลจาก Salesforce ไปยังที่เก็บข้อมูลเมตาเป็นประจำ เมื่อเรามีสิ่งนี้แล้วเราไม่เพียงตรวจจับการเปลี่ยนแปลงในโมเดลข้อมูลเท่านั้น แต่เรายังสามารถเปรียบเทียบโมเดลข้อมูลของสองสภาพแวดล้อม Salesforce ได้อีกด้วย

ข้อมูลเมตาที่จะดาวน์โหลด:

ความปลอดภัยทางไซเบอร์ในวิทยาเขตของวิทยาลัย

• รายการวัตถุที่มีป้ายกำกับและชื่อทางเทคนิคและแอตทริบิวต์เช่น creatable หรือ updatable.
• รายการของเขตข้อมูลที่มีคุณลักษณะ (ดีกว่าที่จะได้รับทั้งหมด)
• รายการค่าตัวเลือกสำหรับฟิลด์รายการเลือก เราจะต้องให้พวกเขาแมปหรือตรวจสอบข้อมูลอินพุตเพื่อหาค่าที่ถูกต้อง
• รายการการตรวจสอบความถูกต้องเพื่อให้แน่ใจว่าการตรวจสอบความถูกต้องใหม่จะไม่สร้างปัญหาสำหรับข้อมูลที่ย้าย

จะดาวน์โหลดข้อมูลเมตาจาก Salesforce ได้อย่างไร ไม่มีวิธีข้อมูลเมตามาตรฐาน แต่มีหลายตัวเลือก:

• สร้าง Enterprise WSDL - ในเว็บแอปพลิเคชัน Salesforce ให้ไปที่ Setup / API เมนูและดาวน์โหลด Enterprise WSDL ที่พิมพ์อย่างชัดเจนซึ่งอธิบายอ็อบเจ็กต์และฟิลด์ทั้งหมดใน Salesforce (แต่ไม่ใช่ค่าตัวเลือกหรือการตรวจสอบความถูกต้อง)
• โทรหา Salesforce describeSObjects บริการเว็บโดยตรงหรือโดยใช้ Java หรือ C # wrapper (ปรึกษา Salesforce API ). ด้วยวิธีนี้คุณจะได้รับสิ่งที่ต้องการและนี่คือวิธีที่แนะนำในการส่งออกข้อมูลเมตา
• ใช้เครื่องมือทางเลือกมากมายที่มีอยู่บนอินเทอร์เน็ต

เตรียมพร้อมสำหรับการย้ายข้อมูลครั้งต่อไป

โซลูชันระบบคลาวด์เช่น Salesforce พร้อมใช้งานทันที หากคุณพอใจกับฟังก์ชั่นในตัวเพียงเข้าสู่ระบบและใช้งานได้ อย่างไรก็ตาม Salesforce เช่นเดียวกับโซลูชัน Cloud CRM อื่น ๆ นำปัญหาเฉพาะมาสู่หัวข้อการย้ายข้อมูลที่ต้องระวังโดยเฉพาะอย่างยิ่งเกี่ยวกับขีด จำกัด ของประสิทธิภาพและทรัพยากร

การย้ายข้อมูลเดิมไปยังระบบใหม่ถือเป็นการเดินทางเสมอบางครั้งการเดินทางสู่ประวัติศาสตร์ที่ซ่อนอยู่ในข้อมูลจากปีที่ผ่านมา ในบทความนี้ฉันได้นำเสนอเคล็ดลับ 10 ประการเกี่ยวกับวิธีการย้ายข้อมูลเดิมและหลีกเลี่ยงข้อผิดพลาดส่วนใหญ่ให้ประสบความสำเร็จ

สิ่งสำคัญคือต้องเข้าใจว่าข้อมูลเปิดเผยอะไร ดังนั้นก่อนที่คุณจะเริ่มการย้ายข้อมูลตรวจสอบให้แน่ใจว่า ทีมพัฒนา Salesforce เตรียมพร้อมสำหรับปัญหาที่อาจเกิดขึ้นกับข้อมูลของคุณ

ที่เกี่ยวข้อง: บทช่วยสอน HDFS สำหรับนักวิเคราะห์ข้อมูลติดอยู่กับฐานข้อมูลเชิงสัมพันธ์