Tag: Error

Solution Importfehler – Entity {0} cannot be disabled for relevance search, because child entity new_someentity is enabled for relevance search

Posted on by Peter Geil

Neue Woche neues Spiel. Von einem Tag auf den anderen begann der Import einer Base-Solution plötzlich fehlzuschlagen und zwar aus einem mir bis dato unbekannten Fehlergrund:

Entity {0} cannot be disabled for relevance search, because child entity ActivityMimeAttachment is enabled for relevance search.

Fehlermeldung des ImportSolution jobs

Erfreulicherweise inkludiert die Fehlermeldung auch gleich eine vermeintliche Lösung und auch insgesamt klingt das Fehlerszenario für mich im Ansatz nachvollziehbar, wenn auch mit einem amüsant-irritierten Beigeschmack.  Denn an den Einstellungen der Relevance Search, welche Teil des System-Customizings ist (Solutioneditor -> Entitäten -> Button “Relevanzsuche konfigurieren” im Entitätssubgrid) wurde in den betroffenen System seit dem letzten Deployment nichts mehr verändert. Zudem ist die Relevance Search Konfiguration nicht Teil einer Solution, sodass diese ohnehin nicht durch einen Solutionimportant zwischen mehreren Systemen verteilt werden kann.

Daher vermute ich dahinter mal wieder einen von Microsofts “Nightly-Harakiri-Patches” für die darunterliegenden Power Plattform bzw. Datenbank, welches häufig mit kleinen heimtückischen Seiteneffekten daherkommt, die erst bemerkt werden wenn es irgendwo gekracht hat.

Lösung

Ein vergleichender Blick auf die Einstellungen der Relevance Search in den betroffenen Systemen, offenbart auch direkt die vermutete Ursache: im Quellsystem liegt eine völlig abweichende Relevance Search Einstellung vor: u.a. betroffen waren die Entities “Notiz” (annotation) und “Anlage” (activitymimeattachment). Nachdem ich für diese die Relevance Search deaktivierte, liefen die automatischen Deployments auch wieder erfolgreich durch.
Vergleich: Relevance Search Einstellungen in den verschiedenen Systemen

Kommentar

Ich würde erwarten, dass derartige Fehler bereits auf Platform-Ebene abgefangen werden, da weil die Child-Relationship der besagten Entität “Anlage” (activitymimeattachment) anhand der Metadaten bereits zum Zeitpunkt der Konfigurationsänderung validiert werden kann, ob es aufgrund nicht mehr auflösbarer Eltern-Kind-Beziehungen später zu einem ungültigen Konfigurations-Stand kommen wird. Beim entfernen einer Elternentität X, müsste die Konfigurations UI bzw. die Plattformlogik dafür sorgen dass vor dem Entfernen der Elternentität, zunächst alle abhängigen Child-Entitäten aus der Relevance Search entfernt werden müssen.

Beware of Dynamics 365 Web API: When attribute and entity have same names

Posted on by Peter Geil

With increasing maturity of the OData Web API exposed by Dynamics 365 CE/CRM its adoption does also steadily increase. From my perspective especially from JavaScript client codes. While the Web API doubtlessly has its sweetspots, it also comes with a lot of pitfalls and limitations (yet) we must get comfortable with and become aware of.

One of these pitfalls which I want to recall today, was already covered back in 2017 by Tip #970: When attribute and entity collide and goes like this:

While (technically) the CRM platform allows an attribute to have the same name as the entity it is defined on, the OData Web API is not capable of handling this and simple throws an “Could not find a property” HTTP 400 error.

Keep in mind when designing the entity model: Avoid naming collisions by never giving an attribute the same schema name as its parent entity.

CRM Online does arbitrarily reduce batch request size / How to intelligently adjust batch size of ExecuteMultipleRequest when request limit is hit

Posted on by Peter Geil

As most of you know, yesterday the Microsoft Azure platform and several of its services/resource types like VSTS and Dynamics 365 were affected by outages and connectivity issues.

I have been affected by this since I was performing regression and penetation tests on a Azure-hosted integration system to a Dynamics 365 system which had its go-live last week. The aforementioned outages manifested as miscellanous network connectivity issues/timeouts and several CRM organization services not responding.

However, one effect caught my attention:

In our custom developed CRM/ERP integration system we make heavy use of ExecuteMultipleRequests and thus, of course, know all restrictions, particularities and limitations inside out. Especially regarding the maximum batch size (ImportSetting.BatchSize), I thought to be aware of. To be more precise, CRM Online by default has a fixed limit of 1000 Organization Requests that may be — simply said — “bundled” into a single ExecuteMultipleRequest and then are executed together in a single physical request to the CRM organization.

Yesterday however, I noticed that many ExecuteMultipleRequests suddenly began to raise service faults saying that the maximum batch size is exceeded which turned on the alert lamps in my mind. Since I conducted the tests and the used fixtures/data by myself and thus know them, and the fact that we used a maximum of 999 requests per ExecuteMultipleRequest, I could surely exclude the reason for these faults to be on our side.

This leads me to the conclusion, the Microsoft could automatically decrease the maximum batch size limit in Dynamics 365 Online organizations in situations where they need to reduce pressure/resource consumption in their cloud landscape. I did not find similar reports on the interweb yet, but will keep this in my backhead for clarification at given time.

Did you encounter a similar behaviour?

Solution

As a solution I wrote a simple proof-of-concept for a mechanism that “intelligently” lowers the number of organization requests put into a single ExecuteMultipleRequest when it attempts a service fault related to MatchBatchSize transgressions. Funny detail: It needs no privileged user account for retrieving a deployment setting but instead uses the “MaxBatchSize” value contained in the service fault detail data object.