Sharepoint lists mirroring issue
Hello, We currently face an issue with sharepoint lists mirroring in microsoft fabric and we have no clue what can happen because the error message is pretty useless : In fact, we are mirroring more than 20 lists but only half of them succeed. The others failed with the following error : Internal system error occurred. ArtifactId: daa35143-...-5aa6accfec68, SequenceNumber: 9 I have linked an eventhouse but the error message is still the same, no more information: Internal system error occurred. ArtifactId: daa35143-...-5aa6accfec68, SequenceNumber: 9 How can I have more information about the issue ? Thank you very much for your help, RegardsFabric Business Events: what delivery guarantees and replay pattern should we design for?
Hi all, I am testing the newer Business Events capability in Fabric Real-Time Intelligence and trying to understand what reliability assumptions should be made for a production design. The pattern I am looking at is roughly: Eventstream → Business Event → Activator → downstream action / User Data Function with Eventhouse enabled so the published business events are also retained for historical analysis. The current documentation explains the publisher/consumer model and shows how Eventstream can publish a governed business event that Activator then consumes. What I have not been able to find clearly documented is the delivery contract between the published business event and its consumers. A few things I am trying to clarify: If an Activator consumer or downstream action is temporarily unavailable, does Fabric retry delivery of the business event? Should consumers assume at-least-once delivery and therefore be designed to handle duplicate events, or is a different delivery model used? Is event ordering guaranteed in any scope, for example for events from the same Eventstream publisher? Since published business events can also be retained automatically in Eventhouse, is that retained history intended to support replay/reprocessing after a consumer outage, or is it primarily an analytical record and replay would need to be implemented separately? Are there documented retry or delivery-retention windows that should be considered when designing an operational workflow? I am mainly trying to understand what a resilient production pattern should look like when the business event triggers something with side effects, where processing the same event twice or silently missing an event would matter. Would you generally make the downstream consumer idempotent and treat Eventhouse as an audit/recovery store, or is there a more Fabric-native pattern for this? Interested to hear how others are approaching this with Business Events and Activator.
Infrastructure and licensing costs for adopting Fabric Planning in production (business case)
Hi everyone, We're evaluating Fabric Planning for a client who wants to adopt it in production, and I need to put together a business case with the associated costs. I've already reviewed the role-based session model (Viewer/Stakeholder/Planner, ~37/168/847 CU-hours per 30-day session) and the F64+ capacity requirement for the XMLA endpoint, but I have a few specific questions on infrastructure and licensing that the documentation didn't fully answer: Per-user licensing: besides the capacity (F64+), is any individual license required (Power BI Pro or Premium Per User) for each Viewer/Stakeholder/Planner user, or does the session's CU consumption already cover full access? Production sizing: beyond the technical F64 minimum, what capacity size would you recommend as a practical floor for a real production scenario with several concurrent users, factoring in the ~30% additional infrastructure buffer (OneLake, XMLA API, etc.)? Billing status: is session/role-based billing already in effect (general availability), or is preview usage still free right now? Regional pricing differences: is there any regional price variation we should account for with a client outside the US (Latin America)? Any real-world sizing experience or business-case examples you can share would be much appreciated. Thanks in advance!Best patterns for ingesting dynamic tax & compliance API data into Fabric Lakehouse?
Hi everyone, We are currently migrating our firm's analytical workloads to Microsoft Fabric. A huge part of our business involves tracking dynamic regional tax rates, company registration statuses, and financial compliance data for startups. Currently, our analysts manually pull this data from external regulatory sources and calculators, like this FBR Sales Tax Calculator, and we import it via Excel/CSV into Power BI. We want to fully automate this in Fabric. What is the recommended pattern for hitting external REST APIs on a scheduled basis (daily) to pull dynamic financial data? Should we use Data Factory pipelines with a Web activity to land the JSON directly into a Lakehouse, or is it better to use a Notebook (PySpark) to handle the API pagination and JSON flattening before writing to delta tables? Would appreciate any architecture advice for handling external financial APIs in Fabric! Thanks.
