You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Mikael Ekblom <mi...@arcada.fi> on 2017/05/04 13:50:33 UTC
Scripted SQL resource
Hi,
We have a scripted sql resource set up to fetch data from our HR system. SEARCH and SYNC capabilities set. Now, as the lines tells us below, the search is returning values to the it-parameter set within the groovy sql eachRow command and its closure. The result array seems to be populated.
16:17:02.952 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[4377]}, ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Efternamn, Value=[Caspar Klaus Sönvis]}, Attribute: {Name=Fornamn, Value=[Berntzen]}, Attribute: {Name=__NAME__, Value=[4377]}, Attribute: {Name=__UID__, Value=[4377]}, Attribute: {Name=__ENABLE__, Value=[true]}], Name=Attribute: {Name=__NAME__, Value=[4377]}} Method: handle
16:17:02.952 DEBUG Return: false Method: handle
But, this is not the case when we try to search and sync from this resource. When we do a "Explore" through the resource and try to view the contents for this particular connector, only the pre-defined attributes __UID__,__NAME__ and __ENABLE__ are visible. The rest of the attributes we set to provision are not visible for some reason. I attached an example of this as a .png.
The attributes Efternamn and Fornamn should also be visible but no.
As the log states, it seems to state that Return: false. Any pullactionhandler that we have created will confirm that this operation will not return anything but the __UID__,__NAME__ and __ENABLE__
. As such we cannot build the usernames accordingly only via this information.
When we connect to this same resource with a dbtable-configuration everything is mapping fine... This will not work in this case though. I first thought that do I now have some ISO-8859-1 conversion issue, but this seems not to be the case. Not for the Dbtable-resource at least.
Another scripted SQL groovy resource towards the same SQL-server and thus we use the same scripted sql bundle version. I set the fetched __UID__values a bit differently
16:21:01.956 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[170776-xxxx]}, ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Ort, Value=[Sibbo]}, Attribute: {Name=efternamn, Value=[Ekblom]}, Attribute: {Name=fornamn, Value=[Mikael]}, Attribute: {Name=Adress, Value=[xxxxxxxxxx]}, Attribute: {Name=__NAME__, Value=[170776-xxx]}, Attribute: {Name=__UID__, Value=[170776-xxxx]}, Attribute: {Name=__ENABLE__, Value=[true]}, Attribute: {Name=personbeteckning, Value=[170776-xxxx]}], Name=Attribute: {Name=__NAME__, Value=[170776-xxx]}} Method: handle
16:21:01.956 DEBUG Return: true Method: handle
With a similar scripted sql-resource through groovy, everything is visible from the built in variables to the other variables stated through the mapping rules. Column formats are the same.
The big question is: why is the example above stating Return false and the other, similar one, not? Has anyone seen this before? What makes a scripted groovy sql resource to return false except for the built in values that must be there?
At times like these, you wish that you could pay for support...:)
Regards,
Mikael
Mikael Ekblom
Systemutvecklare/System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
Re: Scripted SQL resource
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 08/05/2017 09:37, Mikael Ekblom wrote:
>
> Hi,
>
> Never mind, I found it. The groovy-script did not like the fact that
> the columns within the external db resource had different names than
> the attributes internally defined to be mapped for the user class itself.
>
> I solved it by aliasing the columns from the external db within the
> query itself to match the provisioning rule.
>
Glad that you solved! :-)
Regards.
> *From:* Mikael Ekblom [mailto:mikael.ekblom@arcada.fi]
> *Sent:* torstai 4. toukokuuta 2017 16.51
> *To:* user@syncope.apache.org
> *Subject:* Scripted SQL resource
>
> Hi,
>
> We have a scripted sql resource set up to fetch data from our HR
> system. SEARCH and SYNC capabilities set. Now, as the lines tells us
> below, the search is returning values to the it-parameter set within
> the groovy sql eachRow command and its closure. The result array seems
> to be populated.
>
> 16:17:02.952 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
> Value=[4377]}, ObjectClass=ObjectClass: __ACCOUNT__,
> Attributes=[Attribute: {Name=Efternamn, Value=[Caspar Klaus Sönvis]},
> Attribute: {Name=Fornamn, Value=[Berntzen]}, Attribute:
> {Name=__NAME__, Value=[4377]}, Attribute: {Name=__UID__,
> Value=[4377]}, Attribute: {Name=__ENABLE__, Value=[true]}],
> Name=Attribute: {Name=__NAME__, Value=[4377]}} Method: handle
>
> 16:17:02.952 DEBUG *Return: false* Method: handle
>
> But, this is not the case when we try to search and sync from this
> resource. When we do a “Explore” through the resource and try to view
> the contents for this particular connector, only the pre-defined
> attributes __UID__,__NAME__ and __ENABLE__ are visible. The rest of
> the attributes we set to provision are not visible for some reason. I
> attached an example of this as a .png.
>
> The attributes Efternamn and Fornamn should also be visible but no.
>
> As the log states, it seems to state that *Return: false.* Any
> pullactionhandler that we have created will confirm that this
> operation will not return anything but the __UID__,__NAME__ and __ENABLE__
>
> . As such we cannot build the usernames accordingly only via this
> information.
>
> When we connect to this same resource with a dbtable-configuration
> everything is mapping fine… This will not work in this case though. I
> first thought that do I now have some ISO-8859-1 conversion issue, but
> this seems not to be the case. Not for the Dbtable-resource at least.
>
> Another scripted SQL groovy resource towards the same SQL-server and
> thus we use the same scripted sql bundle version. I set the fetched
> __UID__values a bit differently
>
> 16:21:01.956 DEBUG Enter: {Uid=Attribute: {Name=__UID__,
> Value=[170776-xxxx]}, ObjectClass=ObjectClass: __ACCOUNT__,
> Attributes=[Attribute: {Name=Ort, Value=[Sibbo]}, Attribute:
> {Name=efternamn, Value=[Ekblom]}, Attribute: {Name=fornamn,
> Value=[Mikael]}, Attribute: {Name=Adress, Value=[xxxxxxxxxx]},
> Attribute: {Name=__NAME__, Value=[170776-xxx]}, Attribute:
> {Name=__UID__, Value=[170776-xxxx]}, Attribute: {Name=__ENABLE__,
> Value=[true]}, Attribute: {Name=personbeteckning,
> Value=[170776-xxxx]}], Name=Attribute: {Name=__NAME__,
> Value=[170776-xxx]}} Method: handle
>
> 16:21:01.956 DEBUG *Return: true* Method: handle
>
> With a similar scripted sql-resource through groovy, everything is
> visible from the built in variables to the other variables stated
> through the mapping rules. Column formats are the same.
>
> The big question is: why is the example above stating *Return false*
> and the other, similar one, not? Has anyone seen this before? What
> makes a scripted groovy sql resource to return false except for the
> built in values that must be there?
>
> At times like these, you wish that you could pay for support…J
>
> Regards,
>
> Mikael
>
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
RE: Scripted SQL resource
Posted by Mikael Ekblom <mi...@arcada.fi>.
Hi,
Never mind, I found it. The groovy-script did not like the fact that the columns within the external db resource had different names than the attributes internally defined to be mapped for the user class itself.
I solved it by aliasing the columns from the external db within the query itself to match the provisioning rule.
Regards,
Mikael
From: Mikael Ekblom [mailto:mikael.ekblom@arcada.fi]
Sent: torstai 4. toukokuuta 2017 16.51
To: user@syncope.apache.org
Subject: Scripted SQL resource
Hi,
We have a scripted sql resource set up to fetch data from our HR system. SEARCH and SYNC capabilities set. Now, as the lines tells us below, the search is returning values to the it-parameter set within the groovy sql eachRow command and its closure. The result array seems to be populated.
16:17:02.952 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[4377]}, ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Efternamn, Value=[Caspar Klaus Sönvis]}, Attribute: {Name=Fornamn, Value=[Berntzen]}, Attribute: {Name=__NAME__, Value=[4377]}, Attribute: {Name=__UID__, Value=[4377]}, Attribute: {Name=__ENABLE__, Value=[true]}], Name=Attribute: {Name=__NAME__, Value=[4377]}} Method: handle
16:17:02.952 DEBUG Return: false Method: handle
But, this is not the case when we try to search and sync from this resource. When we do a "Explore" through the resource and try to view the contents for this particular connector, only the pre-defined attributes __UID__,__NAME__ and __ENABLE__ are visible. The rest of the attributes we set to provision are not visible for some reason. I attached an example of this as a .png.
The attributes Efternamn and Fornamn should also be visible but no.
As the log states, it seems to state that Return: false. Any pullactionhandler that we have created will confirm that this operation will not return anything but the __UID__,__NAME__ and __ENABLE__
. As such we cannot build the usernames accordingly only via this information.
When we connect to this same resource with a dbtable-configuration everything is mapping fine... This will not work in this case though. I first thought that do I now have some ISO-8859-1 conversion issue, but this seems not to be the case. Not for the Dbtable-resource at least.
Another scripted SQL groovy resource towards the same SQL-server and thus we use the same scripted sql bundle version. I set the fetched __UID__values a bit differently
16:21:01.956 DEBUG Enter: {Uid=Attribute: {Name=__UID__, Value=[170776-xxxx]}, ObjectClass=ObjectClass: __ACCOUNT__, Attributes=[Attribute: {Name=Ort, Value=[Sibbo]}, Attribute: {Name=efternamn, Value=[Ekblom]}, Attribute: {Name=fornamn, Value=[Mikael]}, Attribute: {Name=Adress, Value=[xxxxxxxxxx]}, Attribute: {Name=__NAME__, Value=[170776-xxx]}, Attribute: {Name=__UID__, Value=[170776-xxxx]}, Attribute: {Name=__ENABLE__, Value=[true]}, Attribute: {Name=personbeteckning, Value=[170776-xxxx]}], Name=Attribute: {Name=__NAME__, Value=[170776-xxx]}} Method: handle
16:21:01.956 DEBUG Return: true Method: handle
With a similar scripted sql-resource through groovy, everything is visible from the built in variables to the other variables stated through the mapping rules. Column formats are the same.
The big question is: why is the example above stating Return false and the other, similar one, not? Has anyone seen this before? What makes a scripted groovy sql resource to return false except for the built in values that must be there?
At times like these, you wish that you could pay for support...:)
Regards,
Mikael
Mikael Ekblom
Systemutvecklare/System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467