Comment éviter les erreurs dans les tests MIXED_DML_OPERATION Salesforce créer des utilisateurs

Question

Parfois, dans Salesforce vous les tests doivent créer des objets utilisateur pour exécuter une partie du test en tant que type de speciifc de l'utilisateur.

Cependant, depuis la mise à jour d'été Salesforce 08, les tentatives de créer à la fois des objets utilisateur et des objets normaux (comme les comptes) dans le même test conduisent à l'erreur suivante:

  

MIXED_DML_OPERATION, opération DML sur l'objet de configuration n'est pas autorisé après avoir mis à jour un objet non-setup (ou vice versa): l'utilisateur, objet original: compte

Notez que l'erreur ne se produit pas lorsque vous exécutez les tests à partir Eclipse / Force.com IDE, mais il ne se produit lorsque vous déployez à Salesforce, puis exécutez les tests de Salesforce.

Comment puis-je ré-écrire mes tests pour éviter cette erreur?

Voici un exemple simple d'un test qui provoque l'erreur:

static testMethod void test_mixed_dmlbug() {        
    Profile p = [select id from profile where name='(some profile)'];
    UserRole r = [Select id from userrole where name='(some role)'];
    User u = new User(alias = 'standt', email='standarduser@testorg.com', 
            emailencodingkey='UTF-8', lastname='Testing', 
            languagelocalekey='en_US', 
            localesidkey='en_US', profileid = p.Id, userroleid = r.Id,
            timezonesidkey='America/Los_Angeles', 
            username='standarduser@testorg.com');
    Account a = new Account(Firstname='Terry', Lastname='Testperson');
    insert a;

    System.runAs(u) {
        a.PersonEmail = 'test@madeupaddress.com';
        update a;
    }

}

Answer 1

Peu de gens Salesforce ici encore, je suppose.

J'ai trouvé une solution, je ne sais pas pourquoi cela fonctionne, mais il fonctionne.

Toutes les parties du test qui ont accès à des objets normaux doivent être enveloppés dans un System.runAs qui utilise explicitement l'utilisateur actuel, comme ceci:

User thisUser = [ select Id from User where Id = :UserInfo.getUserId() ];
System.runAs ( thisUser ) {
    // put test setup code in here
}

Ainsi, la méthode exemple text_mixed_dmlbug dans la question, deviendrait:

static testMethod void test_mixed_dmlbug() {  
    User u;
    Account a;      
    User thisUser = [ select Id from User where Id = :UserInfo.getUserId() ];
    System.runAs ( thisUser ) {
        Profile p = [select id from profile where name='(some profile)'];
        UserRole r = [Select id from userrole where name='(some role)'];
        u = new User(alias = 'standt', email='standarduser@testorg.com', 
            emailencodingkey='UTF-8', lastname='Testing', 
            languagelocalekey='en_US', 
            localesidkey='en_US', profileid = p.Id, userroleid = r.Id,
            timezonesidkey='America/Los_Angeles', 
            username='standarduser@testorg.com');
        a = new Account(Firstname='Terry', Lastname='Testperson');
        insert a;
    }
    System.runAs(u) {
        a.PersonEmail = 'test@madeupaddress.com';
        update a;
    }

}

Ensuite, les erreurs de MIXED_DML_OPERATION arrêtent qui se passe.

Answer 2

Il semble que vous avez trouvé une solution de contournement. Je voulais juste essayer et éclaircir pourquoi vous où obtenir cette erreur.

Je pense que vous utilisez dans ce numéro (par http: //www.salesforce.com/us/developer/docs/apexcode/Content/apex_dml_non_mix_sobjects.htm ):

  

sObjects qui ne peut pas être ensemble utilisé dans les opérations DML

     

Certains sObjects exigent que vous effectuez des opérations DML sur un seul type par transaction. Par exemple, vous ne pouvez pas insérer un compte, puis insérez un utilisateur ou un membre du groupe en une seule transaction. Les sObjects suivants ne peuvent pas être utilisés ensemble dans une transaction:

* Group1
* GroupMember
* QueueSObject
* User2
* UserRole
* UserTerritory
* Territory

     Important

La principale exception à   c'est lorsque vous utilisez le runAs   Procédé dans un test.

En outre, le été 08 Notes de version (ce lien est un PDF) disent:

  

Dans les versions précédentes, en un seul   transaction qui a impliqué les déclencheurs,   vous pouvez effectuer des opérations DML sur   plus d'un type de sObject, pour   par exemple, vous pouvez insérer un compte,   puis insérez un utilisateur. Comme l'été   '08, vous ne pouvez effectuer DML   les opérations sur un seul type de sObject   dans la liste suivante de sObjects.

     

Par exemple, vous ne pouvez pas insérer une   compte, puis insérez un utilisateur, ou mise à jour   un groupe, puis insérez un groupe   membre.

     

  
• Groupe
  
• groupmember
  
• QueueSObject
  
• Utilisateur
  
• UserRole
  
• UserTerritory
  
• Territoire
  

     

En outre, l'utilisateur et le territoire maintenant   soutenir l'insert et la mise à jour DML   opérations et UserRole   prend désormais en charge l'insertion, la mise à jour supprimer   et upsert opérations DML.

     

Apex opérations DML ne sont pas pris en charge   sur les sObjects suivants:

     

  
• AccountTerritoryAssignmentRule
  
• AccountTerritoryAssignmentRuleItem
  
• UserAccountTeamMember
  

Answer 3

Ce comportement est en fait documenté dans la documentation de Salesforce: http://www.salesforce.com/us/developer/docs/apexcode/index_Left.htm#StartTopic=Content/apex_dml_non_mix_sobjects.htm?SearchType . Lire où il dit « Important La principale exception à cette règle est lorsque vous utilisez la méthode runAs dans un test "

Answer 4

Je viens de trouver cela dans la documentation:

  

Autres utilisations de runAs

     

Vous pouvez également utiliser la méthode runAs pour effectuer des opérations DML mixtes dans votre test en enfermant les opérations DML dans le bloc runAs. De cette façon, vous contournez l'erreur DML mixte qui est par ailleurs retourné lorsque des objets ou mettre à jour la configuration insertion ainsi que d'autres sObjects. Voir sObjects qui ne peut pas être ensemble dans les opérations DML Utilisé.

Il semble donc que la solution de contournement de RunAs n'est pas une solution mais est assumée par Salesforce comme le seul moyen d'aller par la question mixte DML.

Hope this helps

Référence

Answer 5

Cette erreur est si commune lors d'une tentative de créer l'utilisateur et d'autres enregistrements d'objets dans une transaction unique sommet.

Solution en classe / trigger sommet: utiliser la future méthode pour créer l'utilisateur lorsque rencontré l'erreur

Solution en classe de test: ne pas essayer de créer de nouvelles données de l'utilisateur, utilisez plutôt))>

bout de code à - https://thesalesforcedev.blogspot.com/2019/07/ mixeddmloperation-DML-opération-on.html