[midPoint] Question about database connector and error handling
Shilen Patel
shilen at duke.edu
Wed May 24 16:14:38 CEST 2017
Hi folks,
I am relatively new to using MidPoint and have recently started to look at how to integrate with a resource that stores user objects in a database table (Oracle). I'm using the built-in DatabaseTableConnector (v1.4.2.0). The database table is only a provisioning target. So only outbound mappings and nothing inbound. A have a couple of questions that I was hoping I could get some insight into.
1. Most of the data needs to go to a single table. However, there is one attribute that needs to go to another table. The other table has a foreign reference to the primary table. Does the built-in DatabaseTableConnector connector provide a means to insert a row into the secondary table when a row is inserted into the primary table? If not, I think I know how to work around it. I think I can easily extend the connector to do what I need to do there, but wanted to make sure there wasn't another way.
2. I'm trying to figure out how error handling is supposed to work. I've read through some of the background wiki pages, e.g. https://wiki.evolveum.com/display/midPoint/Consistency+mechanism
I want to see what would happen when the target database is down (e.g. unexpected outage, scheduled maintenance, etc). I figure when I have a lot of these external resources, I need to make sure a single resource having an issue doesn't make the whole MidPoint instance have issues. So to force an error, I changed the database and jdbc connection url strings to have an invalid SID. But then, using the web interface, if I try updating any attribute on a user that has a linked account for that resource, I get the following error:
2017-05-24 09:37:02,270 [] [Thread-21] ERROR (com.evolveum.midpoint.provisioning.ucf.impl.IcfUtil): ICF Exception java.lang.RuntimeException in connector:cbf461fb-12f8-4fb3-b705-ceba4b7af0ab(ICF org.identityconnectors.databasetable.DatabaseTableConnector v1.4.2.0): resource:48b3a4c2-0a55-426d-b21a-bed707837e72(TestDB) while getting object identified by ICF UID '102': java.sql.SQLException: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
java.lang.RuntimeException: java.sql.SQLException: Listener refused the connection with the following error:
ORA-12505, TNS:listener does not currently know of SID given in connect descriptor
at org.identityconnectors.dbcommon.SQLUtil$2.access(SQLUtil.java:207) ~[dbcommon-1.4.2.0.jar:na]
at org.identityconnectors.common.security.GuardedString.access(GuardedString.java:116) ~[connector-framework-1.4.2.18.jar:na]
at org.identityconnectors.dbcommon.SQLUtil.getDriverMangerConnection(SQLUtil.java:198) ~[dbcommon-1.4.2.0.jar:na]
at org.identityconnectors.databasetable.DatabaseTableConnection.getNativeConnection(DatabaseTableConnection.java:102) ~[connector-databasetable-1.4.2.0.jar:na]
at org.identityconnectors.databasetable.DatabaseTableConnection.createDBTableConnection(DatabaseTableConnection.java:74) ~[connector-databasetable-1.4.2.0.jar:na]
at org.identityconnectors.databasetable.DatabaseTableConnector.getConn(DatabaseTableConnector.java:212) ~[connector-databasetable-1.4.2.0.jar:na]
at org.identityconnectors.databasetable.DatabaseTableConnector.checkAlive(DatabaseTableConnector.java:192) ~[connector-databasetable-1.4.2.0.jar:na]
at org.identityconnectors.framework.impl.api.local.ConnectorPoolManager$ConnectorPoolHandler.testObject(ConnectorPoolManager.java:149) ~[connector-framework-internal-1.4.2.18.jar:na]
at org.identityconnectors.framework.impl.api.local.ConnectorPoolManager$ConnectorPoolHandler.testObject(ConnectorPoolManager.java:83) ~[connector-framework-internal-1.4.2.18.jar:na]
at org.identityconnectors.framework.impl.api.local.ObjectPool.borrowObject(ObjectPool.java:250) ~[connector-framework-internal-1.4.2.18.jar:na]
at org.identityconnectors.framework.impl.api.local.operations.ConnectorAPIOperationRunnerProxy.invoke(ConnectorAPIOperationRunnerProxy.java:87) ~[connector-framework-internal-1.4.2.18.jar:na]
I can provide the full stack trace if it would be useful. I was expecting/hoping that any error on an individual outbound resource wouldn't fail the entire transaction. I saw that there is a configuration option called "Rethrow all SQLExceptions", but that didn't seem to change this particular behavior. I think ideally the update of the attribute in MidPoint would succeed and the update to the resource would either be automatically retried later or just ignored and handled by a reconciliation task. Is that possible? Am I doing something wrong?
Thanks!
- Shilen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20170524/4cda8b54/attachment.htm>
More information about the midPoint
mailing list