midPoint SAP and Google Workspace connectors

Choose the SAP connector by the SAP system your identities actually live in, then check its support status before anything is scoped. The Evolveum connector catalog lists three entries relevant to this topic. The SAP R/3 connector is maintained by Evolveum and listed as supportable. The SAP UME (Portal) connector, written by AMI Praha, is listed as community. The Google Apps connector is listed as supportable and is maintained by Evolveum and the community. If your accounts sit in an ABAP-based SAP R/3 landscape, the first is the entry to examine. If your user administration runs through the SAP Portal's User Management Engine, the second applies. Confirm which of these matches your own environment before drafting the design. The status label tells you who stands behind the connector. A supportable connector is one Evolveum lists as a maintained part of its supported catalog, so questions about its behavior and defects can go through Evolveum's support channel. A community connector is developed and maintained outside that support commitment, even when it is useful and widely deployed. Community status does not mean the connector is unsafe or unfinished, but it does mean your team must decide who will diagnose failures, test upgrades and carry the fix when something breaks. Record that decision in the design, because it changes the effort your organization carries after go-live. Support status affects what a subscription covers. Evolveum offers Product Support subscriptions for resolving product bugs, available on an 8x5 next-business-day or a 24x7 service level agreement. Platform Subscriptions add feature development and influence over the roadmap. These are different things. A bug fix path is not the same as a request to build new SAP attributes or a new provisioning behavior, and the page does not list prices, so the cost of each option must come from a written quote. Ask which tier covers the work you plan and how the 8x5 and 24x7 options differ for your incident response needs. Before a connector is put in scope, get written confirmation from Evolveum of which connector and which version your subscription covers. Ask for the exact connector name as listed in the catalog, the version range, and whether the coverage extends to the SAP release in your landscape. For the community connector, ask Evolveum to state in writing that it falls outside the subscription, and plan your own test cycle and ownership. Put these answers in the statement of work so that the connector scope, support obligations and acceptance tests match.

Correlation decides whether an SAP or Google Workspace account that already exists is linked to a midPoint identity or treated as a new one. It is the first decision that shapes the connector work. If the matching is wrong, midPoint either creates a second identity for someone who already has access or links an account to the wrong person. Before any connector is configured for enforcement, the team should write down, for each target, which account attribute is matched to which midPoint user attribute, and what happens when no match or several matches are found. The correlation rules should be agreed with HR or the identity owner, not set by the integration team alone. HR usually holds the attributes that identify a person most reliably, such as a personnel number, legal name and employment status. The owner also needs to answer practical questions: whether a personnel number is reused after a rehire, how name changes are handled, whether contractors are recorded in the same source as employees, and how shared or service mailboxes in Google Workspace are classified. Engineers can propose matching logic, but the owner should confirm which identifiers the organization trusts.

Existing accounts must be linked before enforcement is turned on. In a non-enforcing run, midPoint reads the SAP and Google accounts, applies the correlation rules and shows the proposed links without changing anything on the target systems. The team reviews those proposals, resolves the exceptions and only then moves reconciliation to enforcement. If enforcement runs first, accounts that were not yet linked can be treated as unowned and changed or removed, which is hard to reverse for people who still need access. Confirm with the Evolveum connector documentation and with your SAP and Google administrators which reconciliation behavior the chosen connector version supports, and test the whole sequence on a subset of users first.

Duplicate and orphaned accounts should be reported for review, not handled automatically. A duplicate is either one target account that matches several midPoint users or several target accounts that match the same user. An orphan is a target account with no matching midPoint user. The report should list each case with the attributes used, the candidate matches and the current account status, so a reviewer can decide whether to link, correct the source data or disable the account. The team should agree in advance who receives these reports, who decides, and how quickly exceptions must be cleared before the next enforcement run.

The trusted identifiers are the core design decision for these connectors. They must be chosen and documented before reconciliation runs in enforcement mode, because every later step depends on them, including joiner and leaver handling and access certification. A practical check is to sample a set of users from HR, SAP and Google Workspace and confirm that the chosen identifier is present, unique and maintained in each system. Where a sample shows gaps or conflicts, the owner should correct the source data first. Record the final rules, their owner and the review process in the project documentation so that auditors and future administrators can trace how each link was created.

Run the SAP and Google Workspace connectors through a fixed, read-only sequence before midPoint is allowed to create, change or remove any account. The sequence has four stages: a connection test, schema discovery, a reconciliation that only reports, and a pilot with a small set of test identities. Each stage has a clear exit condition, and the next stage starts only when the previous one passes. Before you begin, confirm which connector applies to your target. The Evolveum catalog lists the SAP R/3 connector as supportable and maintained by Evolveum, and the SAP UME (Portal) connector from AMI Praha as community. The Google Apps connector is listed as supportable and maintained by Evolveum and the community. Your support expectations depend on that status, so record it in the test plan.

Start with the connection test and schema discovery. Use a dedicated service account in the SAP non-production client or the Google Workspace test domain, and confirm that midPoint can authenticate and read the expected object types. Compare the attributes midPoint discovers with the attributes your mappings depend on, especially the identifiers used for correlation, such as personnel number or primary email. Check which attributes the connector can write and which are read-only in your configuration. Save the discovered schema as a baseline. If an attribute your mapping expects is missing, fix the mapping or the target permissions before you go further, because later stages will otherwise produce misleading results.

Next, run a reconciliation with changes reported but not applied. Review the account links first. Each test identity should link to exactly one midPoint user, accounts without an owner should appear in the report as unmatched, and no identity should link twice. Then check group and role results. For SAP, compare the roles or composite roles in the report with the assignments your midPoint role model intends. For Google Workspace, compare the group memberships the report proposes with the expected group list for each test identity. Review sample records by hand, not just the totals. Any unexpected link or membership is a reason to stop and correct the mapping or correlation rules.

Run the pilot against the test identities only. Create a joiner, change a mover attribute, and then process a test leaver. Verify each step in the target system, not only in midPoint. For the leaver, confirm what removal means in your policy: whether the SAP user is locked or deleted, whether assigned roles are withdrawn, and whether the Google account is suspended and removed from groups. Check that production identities were not touched. Confirm the behavior with your SAP and Google administrators, and document any step that needs manual handling. Only after the pilot results match the agreed policy should enforcement be considered.

Record the evidence as you go. Log the midPoint version, the connector version, the target system version or test domain, the date, the scope of identities used and the result of each stage, including deviations and how they were resolved. midPoint 4.8 is a long-term support release supported until 17 October 2028, and midPoint 4.11 is planned for 21 October 2026, so state which version was tested and whether it is covered by your planned support. A signed test record gives the subscription conversation a fixed reference point and gives auditors a traceable link between the configuration they review and the behavior that was tested. Keep the record with the connector configuration in version control.