Mohamed Mansor’s Post

Dual write Triggering: Scenario: Some fields in F&O behave differently than others when triggering a update in dual write.  In one of the entities, Sales Order Line V2, any changes to SalesOrderLineStatus do not trigger an update in CE. Meanwhile, if another field on that record is changed, then the new value of SalesOrderLineStatus come through too along with the other change. The Field is also in the dw map and is one-way only FO > CE (not bi-directional) To provide some context in how the triggering happens in the F&O->CE direction. During map enablement, the platform walks through the entity definition and decides which backing tables it needs to subscribe to. For most entities this is all you need, but for some complex cases (like entities based on views, etc), the platform for some reason doesn't realize a certain table has an impact on the entity. An example of this is in CustCustomerV3Entity::getEntityDataSourceToFieldMapping() where we say "also watch these tables, and these are the fields of the CustCustomerV3Entity that will have the recid of that table if a record change impacts the entity".   Note, you can also explicitly remove one of the automatically tracked datasources as is done in the CustCustomerV3Entity::dualWriteShoudlSkipDataSource() example.   Then at runtime, insert/update/delete events from the underlying table are tracked by the D365FO kernel. Any time one happens, we walk back up that entity chain to compute which entity records were impacted, and send these over to CE.   So generally places where a change isn't auto-detected would be scenarios where from metadata alone, D365FO can't compute what table change would impact what entity. Things like computed fields where X++ logic is used to build the field value (and from metadata we don't know what tables that X++ logic may have queried. Contact me at tom.burnett@btconnect.com for more information on this or anything related to Dual write.

While no-code might sound tempting for quick setup, there are big trade-offs you can't ignore when it comes to maintainability, flexibility, and performance. Here's 10 reasons why, as well as why having control over your code is needed for reliability and scalability in your data systems. https://bit.ly/3Bx3G7T

It usually helps to understand the business for whatever system you are developing, this way you can develop a sense of where the data and logic should live. “”” Assuming changes are to data and/or logic: - Does the data belong uniquely in any system we own? Are, or should we be, its canonical custodians? - If so, review our data models. We might not be meeting a reasonable expectation. - If not: Does this data already exist somewhere else? Is there a more natural home for it? Can those who need the change manage that data instead? Does the logic belong uniquely in any system we own? Is it a state change to data we own, or an operation we’re responsible for? - If so, review our logic. We might not be meeting a reasonable expectation. - If not: Does this behaviour already exist somewhere else? Is there a more natural home for it? Can those who need the new logic implement it themselves in a decoupled way (ex: we agree to own the data, but we publish change events which they can listen to)? “”” #softwaredesign #softwareengineering #softwarearchitecture

At Certa.ai, we as a team pride ourselves on our top-tier engineering, but even the best teams can encounter unforeseen issues. This is the story of an incident where we faced and solved a mysterious surge in database activity that caused unexpected IOPS increases 📈. Read about how we identified the root cause and implemented effective solutions to restore performance and maintain a seamless customer experience. I have shared our learnings in this article, and I bet this will be a good read. 📖 https://lnkd.in/dUk3hrhF

You may ask why the API response time is so long. It’s mainly because of the product characteristics, it’s a data product, there will be a lot of data aggregation and analysis, and the API response will be the result of a period of analysis. Therefore, in general, there will be a longer latency.

Let's talk about a way to guarantee bad data never enters production - the Write-Audit-Publish (WAP) pattern. We always recommend data practitioners to borrow more concepts from software engineering to build data products that are trusted by the broader business and, ultimately, save the cost of leaky data pipelines. In our most recent article, we show how implementing the WAP pattern can ensure you're: 🤲 Always working on production data in an isolated environment (dev/staging/prod environments) 🤝 Collaborating securely with custom approval flows (GitOps) ✋ Preventing faulty builds from going into production (CI/CD) Read on in our most recent GitOps for Data piece: https://lnkd.in/exirNEsv

🚀 Boost API Performance with Indexing! Is your API sluggish? The solution might be as simple as indexing your database! 🗃️ Here’s why indexing matters: 1️⃣ Faster Queries: Indexes help the database find data quicker, just like an index in a book. Instead of scanning every row, it pinpoints the exact match. 2️⃣ Optimized Joins: When combining tables, indexed columns make the process seamless. 3️⃣ Improved Sorting: Indexes speed up ORDER BY operations, making sorted results lightning-fast. 📝 Quick Tips: • Index columns you search or filter by often (e.g., email, id). • Avoid over-indexing—it can slow down write operations. • Use composite indexes for multi-column queries. A well-indexed database is the key to blazing-fast APIs!

Hi! In this new blog entry, I discuss a potential approach to designing data abstraction, from specifying the object and its functionality to the tests that must be passed to conclude development.

The 𝐂𝐚𝐜𝐡𝐞-𝐀𝐬𝐢𝐝𝐞 𝐏𝐚𝐭𝐭𝐞𝐫𝐧 is a powerful strategy for enhancing API performance by reducing database load and improving response times. When combined with the MediatR library in a .NET environment, it offers an effective way to manage caching as a cross-cutting concern. By caching the results of frequently executed queries and selectively invalidating them after updates, you can ensure your APIs remain fast and efficient, even under heavy load. I recently published an article detailing how to implement the Cache-Aside pattern with MediatR in my newsletter. If you're interested in learning more, check it out here:

In our latest Platformatic blog, we are continuing our Fastify Fundamentals series, looking at how to validate your API's data and serialize it to be read and stored in a reliable data structure. Check it out👇 https://hubs.ly/Q02m2hk70