Why do we need a System or Service User?

A system user is typically utilized by the AEM backend code which has privileges to create, read, update, and delete nodes in the JCR using a session.

Developers have to close the session after the tasks are performed.

If you forget to close the sessions that you've opened, your AEM can get overwhelmed with too many open sessions. This can cause your AEM to run out of memory and crash. In simpler terms, not closing sessions properly can lead to memory issues and system crashes in AEM.To learn more about this topic, take a look at this blog How to Close ResourceResolvers, and Sessions

How to create a system user or service User

Creating a service user in Adobe Experience Manager (AEM) as a Cloud Service requires configuring the RepositoryInitializer

What is repoinit (RepositoryInitializer configuration)?

Repoinit is a tool for setting up a content repository in a specific way. It is like a recipe that tells the repository how to create nodes, properties, service users, and access control policies, as well as register JCR namespaces, node types, and privileges.

Full documentation is found here.

Here is a simple example of a repoinit script:

{
    "create node /content/my-site"
    "create property /content/my-site/title "My Site"
    "create service user mySystemUser"
    "grant permission to mySystemUser to read and write /content/my-site"
}

Here are the steps to create a service user in AEM Cloud:

Steps 1: Set up the "org.apache.sling.jcr.repoinit.RepositoryInitializer" PID configuration.

filename: apps/mysite/osgiconfig/config/org.apache.sling.jcr.repoinit.RepositoryInitializer~mySystemUser.cfg.json

{
  "scripts": [
    "create path (sling:OrderedFolder) /content/dam/mysite",
    "create path (nt:unstructured) /content/dam/mysite/jcr:content",
    "create path (cq:Page) /content/mysite",
    "create path (cq:PageContent) /content/mysite/jcr:content",
    "create path (sling:Folder) /conf/mysite",
    "create service user mySystemUser with path /home/users/system/mysite",
    "set ACL for mySystemUser \r\n  allow jcr:all on /content/mysite\r\n  allow jcr:all on /conf/mysite\r\n  allow jcr:all on /content/dam/mysite\nend"
  ]
}

Description of Step 1:

This script enables the creation of a system user named "mySystemUser," which will be situated within the folder structure at /home/users/system/mysite.

The system user, mySystemUser, will have ACL (Access Control List) privileges configured to:

• allow read, write, and replicate for all JCR resources that exist under /content/mysite

• allow read, write, and replicate for all JCR resources that exist under /conf/mysite

Steps 2: Set up the "org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended " PID

filename:

apps/mysite/osgiconfig/config/org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended~mySystemUser.cfg.json

{
  "user.mapping": [
    "mysite-core.core:mySystemUser=[mySystemUser]"
  ]
}

Deployment: -

Make this change and deploy it locally, you will able to see the service or system user inside this folder (/home/users/system/mysite)

Note: If you are not able to see system users in your local please restart your AEM.

Sample code to get a resource resolver using mySystemUser as the Sling sub-service

final Map<String, Object> authInfo =
        ImmutableMap.of(ResourceResolverFactory.SUBSERVICE, "mySystemUser");
try (ResourceResolver resolver =
        resourceResolverFactory.getServiceResourceResolver(authInfo)) {

    final Resource blog = resolver.getResource("/content/mysite/blog");
    logger.info("got {}", blog.getPath());

} catch (LoginException e){
    logger.error("could not open resource resolver", e);
}

Common Errors occurs related to repoinit configurations in AEM :

Sometimes you may find that your AEMaaCS pipelines are failing due to the repoinit

To Troubleshoot that error please check the below points

1. Syntax Errors: Incorrect syntax in repoinit scripts can lead to parsing errors. Ensure that the script is properly formatted and follows the repoinit language rules.

2. Invalid Paths: If the paths specified in repoinit scripts do not exist or are incorrect, you may encounter errors when trying to apply the configuration.

3. Access Denied: Insufficient permissions for the user executing the repoinit script can result in errors when trying to make changes to the repository.

4. Node Overwrite: If the repoinit script attempts to create a node that already exists without specifying whether it should be overwritten, it can cause errors.

5. Incompatible Actions: Some actions specified in repoinit scripts may be incompatible with the existing repository state or configurations. This can lead to conflicts and errors.

6. Timing Issues: Repoinit scripts are executed during repository startup or when triggered manually. If the script depends on certain conditions that are not met at the time of execution, errors can occur.

7. Resource Dependencies: If the repoinit script relies on external resources (e.g., files, services) that are unavailable or misconfigured, it can result in errors.

8. Logging and Debugging: Inadequate logging and debugging in the repoinit script can make it challenging to diagnose and troubleshoot errors.

9. Conflict Resolution: If multiple repoinit scripts are applied, they may conflict with each other or with existing repository configurations. Resolving these conflicts is essential to prevent errors.

10. Version Compatibility: Repoinit scripts may not be compatible with the version of AEM being used, leading to errors or unexpected behavior.

To address these issues, it's crucial to thoroughly review and test your repoinit scripts, ensure that they align with your AEM environment's requirements, and monitor the logs for any error messages or warnings during script execution. Additionally, refer to the official AEM documentation and best practices for repoinit configuration to avoid common pitfalls.

If you have any questions, please don't hesitate to ask! Linkedin