Error Cannot invoke "java.util.Map.keySet()" because "this.fImportSourceFields" is null
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2025 03:38 AM
I tried to "Test load 20 records" from SCCM.
The error:
The connection use Integrated Auth, and it is success:
Is it necessary for the other authentication method to work as well? When we try to use it, it doesn’t work with a domain Windows user because it tries to connect using SQL authentication.
Thanks, regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2025 06:19 AM
Hello @davidnevado,
Please refer to the below link's:
https://www.servicenow.com/community/itom-forum/error-cannot-invoke-quot-java-util-map-keyset-quot-b...
https://www.servicenow.com/community/cmdb-articles/sg-sccm-service-graph-connector/ta-p/2854458
If this is helpful, please hit the thumbs up button and accept the correct solution by referring to this solution in future it will be helpful to them.
Thanks & Regards,
Abbas Shaik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2025 07:32 AM
Hi @davidnevado ,
1 Integrated vs SQL Authentication
* When SCCM JDBC Data Source is configured to use Integrated Auth (Kerberos/NTLM), it authenticates using the MID Server’s Windows identity.
* SQL Authentication requires explicit SQL credentials (username/password defined in the JDBC URL).
It is not mandatory to configure both methods. Choose one authentication method that works end-to-end:
* Preferably Integrated Auth if your MID Server is domain-joined and has access.
* Only use SQL Auth if your organization allows SQL user accounts.
If Integrated Auth works, you do not need SQL Authentication unless your design specifically requires it.
2 Why “Test load” fails with null fImportSourceFields
This often happens if:
* The Data Source connection test is successful, but the query to pull the data fails.
* The credentials used don’t have sufficient SELECT permission on the target SCCM tables/views.
* The MID Server used doesn’t have proper access.
* The import set table definition doesn’t get any columns back → so fImportSourceFields is null.
Check the import log:
* Confirm the MID Server used.
* Validate the SQL executed.
* Look for permission errors (e.g., permission denied).
3 Recommended Steps to Fix
Verify Integrated Auth works end-to-end:
* Ensure MID Server service runs as a domain account with SELECT permission on SCCM DB.
* Confirm the JDBC URL uses:
jdbc:sqlserver://<server>;databaseName=<db>;integratedSecurity=true;
Remove SQL Authentication Data Source if you don’t need it:
* Avoid running the test against that connection.
Check DB permissions:
* MID Server domain account (for Integrated Auth) needs:
* SELECT on all required SCCM views/tables.
* Read access to the schema.
Update Data Source:
* Make sure the Data Source references the correct JDBC connection (Integrated Auth).
* Rebuild Transform Maps if schema changed.
Retest:
* Use “Test load 20 records” again.
* If it still fails, open the import log to see exact SQL / permission error.
⚙ Other best practices:
* MID Server should always run under a domain user if you use Integrated Auth.
* Validate JDBC driver version supports Integrated Auth.
* Only keep one active JDBC connection per use case to avoid conflicts.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025