<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
I can see two slightly separate issues here:<br>
<br>
Issue 1: Complex attribute that is created in two mappings.<br>
<br>
If both mappings are inbound mappings in the same resource you may
try to use this:<br>
<inbound><br>
<source><path>attributes/foo</path></source><br>
<source><path>attributes/bar</path></source><br>
<expression>.....</expression><br>
<target><path>extension/whatever</path></target><br>
</inbound><br>
<br>
The inbound mappings and outbound mappings and user template
mappings - all work in the same way. The inbound mappings just
have default pre-set source. But you might be able to override it.
The mechanism was designed for this. But we have never tested this
override and therefore I'm not sure if it works.<br>
<br>
If the mappings are not from the same resource then it will get
very tricky. You may try to use two separate mappings to get the
"id" and "value" into user extension and then combine it in object
template. But this will get very (I mean VERY) complex as this
attribute is obviously multi-valued.<br>
<br>
Maybe you can simplify the situation by avoiding the XML. E.g. use
string values of "1:a", "2:b" and so on. This is not so elegant
but as we are slowly moving away from XML this may in fact be a
better solution for the future.<br>
<br>
But ... maybe you do not need this at all ... because:<br>
<br>
Issue 2: Handling many types of groups<br>
<br>
MidPoint is designed for this. There is a mechanism called
"intent". This is something like "account type" or "group type".
The intent is something like a unique identifier of
account/group/whatever that is linked to a user (or role or org).
Therefore if you have a specific user that has a linked shadows,
each shadow must have unique combination of
(resourceOid,kind,intent) triple. See
<a class="moz-txt-link-freetext" href="https://wiki.evolveum.com/display/midPoint/Kind%2C+Intent+and+ObjectClass">https://wiki.evolveum.com/display/midPoint/Kind%2C+Intent+and+ObjectClass</a><br>
<br>
So, you can use "intent" as your group type identifier. Intents
are defined in schemaHandling, therefore they can be modified on
runtime. We are using a very similar mechanism in one of our
solution. We are creating the groups in different OUs as well. I'm
sure Ivan can provide more details on this.<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
<br>
<br>
<br>
On 07/03/2014 06:40 PM, Deepak Natarajan wrote:<br>
</div>
<blockquote cite="mid:53B58792.6000502@trilobytesystems.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<span><br>
Hi Radovan -<br>
<br>
I would like to return to this issue we discussed earlier.<br>
<br>
You mentioned :<br>
<br>
</span><span>"When it comes to your specific case I'm sure that
the data can be represented in an alternative way without the
use of attributes. Of course you can use this:
<br>
<group>
<br>
<id>1</id>
<br>
<value>a</value>
<br>
</group>
<br>
<group>
<br>
<id>2</id>
<br>
<value>b</value>
<br>
</group>
"<br>
<br>
I would like to use this, but am wondering how the inbound
mappings would be set up in order to set <id> and
<value> in separate mappings. (and they should be for the
same <group> instance)<br>
<br>
<br>
</span><span>In our use case, we have different group "types".
What this boils down to is that these groups belong in different
OU's (i.e group Foo with type A is under ou=A,o=root,.. and
group boo with Type B has a dn cn=Boo, ou=B, o=root etc.) - And
more types can arise in the future.<br>
<br>
In your org sync example, you kept it simple and added all the
groups under on OU. I took this a bit further and examine the
group name for clues as to where it belongs (it was obvious at
one point - but our customer has introduced some new ideas
*sigh*)<br>
<br>
I am trying to build an elegant, flexible solution for this. To
somehow propagate these "group types" to my Midpoint User (who
has a sequence of <group>'s), onto my Roles and then
finally use this to provision the groups correctly in the
various OU's.<br>
<br>
I started off by trying to have a better extension schema :<br>
<groups><br>
<group><br>
<name>foo</name><br>
<type>A</type><br>
<group><br>
...<br>
...<br>
</groups><br>
<br>
I'm not sure if this is possible (I have read your detailed
input on XML usage within Midpoint) and how I would do inbound
mapping for such extension elements (considering that my source
feed can provide group name and type)<br>
<br>
And then I would have to deal with role mappings in the user
template in order to propagate this as an extension atttribute
of Role, and then use this value to figure out the base dn for
the group (I have installed my static custom class in Midpoint
that returns this value). The idea is to be able to inject new
group types at runtime.<br>
</span><br>
Essentially I'm looking for a pattern to solve the general case of
mapping our source systems rich attributes onto various extended
attributes for key Midpoint focal objects such as User &
Group.<br>
<br>
A use case for us is that when a department has a new attribute in
the source system (e.g this department is only for "managers"), we
need this to translate to a group that is under a specific OU (and
this is independent of org sync - i.e users assigned to orgs).<br>
<br>
I've dumped a lot here, but any thoughts? :)<br>
<br>
As always, thanks in advance.<br>
<br>
BR/Deepak<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:538622C7.5040308@evolveum.com" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr">
<div style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px">
<div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="radovan.semancik@evolveum.com"
photoname="Radovan Semancik"
src="cid:part1.04040606.09070205@evolveum.com"
name="postbox-contact.jpg" height="25px" width="25px"></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true"
href="mailto:radovan.semancik@evolveum.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Radovan Semancik</a></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">May
28, 2014 at 7:54 PM</span></font></div>
</div>
</div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">Hi Deepak,
<br>
<br>
I guess I have a bad news for you. But this is quite a long
story, so let's start at the beginning.
<br>
<br>
When we have designed midPoint a couple of years ago we have
built it quite tightly on top of XML. That was still the
obvious choice at that time and also some kind of a best
practice. And it was not a bad choice. Especially considering
that alternatives such as JSON were still it their infancy ...
and actually they haven't evolved a bit in all these years -
but that's a different story. So, we have built midPoint on
top of XML.
<br>
<br>
But the XML stroke back. I was not naive and I was aware that
XML is not perfect when we started with midPoint. But I
somehow expected that we can live with it at least for few
years. I was wrong. XML and XSD and WSDL are terribly bad at
handling dynamic schemas. I mean schemas that are only
available at runtime. MidPoint schema extension is one example
of such schema. But there are many more examples: resource
schema, connector schema, reports, ...
<br>
<br>
Most other IDM system obviously deal with this problem by
ignoring it. They do not support schema at all. But this was
not the path that we wanted to take with midPoint. MidPoint is
fully schema-based from the bottom (connectors) to the top
(GUI). And there are huge advantages to this architecture. But
there are also challenges. And dealing with XSD and especially
Sun XML libraries was a huge challenge.
<br>
<br>
And that was the origin of "Prism Objects". We started to
slowly replace XML libraries with a more generic data
representation layer. See:
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://wiki.evolveum.com/display/midPoint/Prism+Objects">https://wiki.evolveum.com/display/midPoint/Prism+Objects</a>
<br>
<br>
That was approximately the time when JSON became more popular
than XML. And midPoint users started to ask about JSON
support. I personally do not like JSON way of doing things.
But we need to listen to user requests. And we have realized
that we can easily support JSON and also other languages with
our Prism layer. And I actually see an advantage in using
readable languages such as YAML. Therefore we have chosen to
go for language independence. XML is just one of possible data
representation languages now. JSON and YAML will be available
soon.
<br>
<br>
Currently midPoint (v3.0) is almost completely based on Prism.
It is not using the XML layer directly perhaps except for
several places that we plan to rewrite in next releases. This
gives us the ability to represent data theoretically in any
reasonable format. XML is the primary one. But it is not the
only one.
<br>
<br>
And now it gets to the point of XML attributes. XML is a very
strange format for data representation. It has nice features
(such as safe extensibility with namespaces) and it has really
bad features. Attributes are one of the worse features.
Non-structured data item can be represented both as an
attribute and as an sub-element. This creates a dichotomy that
puzzled software engineers almost since XML was created. And
it is a deadly trap for language-neutral data abstractions
such as our Prism. Also languages such as JSON do not have
attributes at all. And even though we try to have complete
schema for everything there are some corner cases when we need
to work without a schema. And then there may be problem
whether to represent JSON key as XML attribute or sub-element.
<br>
<br>
Therefore we have decided to slowly phase out the support for
XML attributes. MidPoint version 3.0 interprets attributes in
the same way as sub-elements. And in fact these are
interchangeable at many places in midPoint XML structures. And
more places will appear in next versions. This is the plan for
the entire 3.x generation. The 4.x versions will probably not
use attributes at all.
<br>
<br>
So, the use of attributes is still somehow supported. But not
recommended. And the way how you try to use the attributes as
a map will not work in midPoint 3.x. It is not compatible with
our data representation.
<br>
<br>
When it comes to your specific case I'm sure that the data can
be represented in an alternative way without the use of
attributes. Of course you can use this:
<br>
<group>
<br>
<id>1</id>
<br>
<value>a</value>
<br>
</group>
<br>
<group>
<br>
<id>2</id>
<br>
<value>b</value>
<br>
</group>
<br>
<br>
And there is another catch. As we are moving away from XML we
also have to move away from XML-dependent mechanisms. Such as
XPath. Therefore XPath has limited capabilities in midPoint
3.x. In fact if you define a schema then midPoint will not
think about the data in XML terms. It will not see XML
elements any more. It does not see the document, it sees the
data. It will see the data structure as multi-value structured
property "group". XPath may not be applicable here.
<br>
<br>
Therefore I guess this is still not the best way to represent
your data. Maybe I could help you design the data structure if
you describe the way how you plan to use the group data from
the user object.
<br>
<br>
</div>
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr">
<div style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px">
<div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="dnataraj@trilobytesystems.com"
photoname="Deepak Natarajan"
src="cid:part4.09050209.01020309@evolveum.com"
name="compose-unknown-contact.jpg" height="25px"
width="25px"></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true"
href="mailto:dnataraj@trilobytesystems.com"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Deepak Natarajan</a></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">May
26, 2014 at 1:32 PM</span></font></div>
</div>
</div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<div>Hi everyone -<br>
<br>
I am trying to achieve the following inbound mapping :<br>
<br>
from resource :<br>
"groups" : "a_1,b_2,c_3,d_4"<br>
<br>
to<br>
<br>
<user><br>
<group id="1">a</group><br>
<group id="2">b</group><br>
<group id="3">c</group><br>
</user><br>
<br>
My custom schema extension seems to be accepted by Midpoint.
I have<br>
extended the UserType to support a multi-valued child
element <group><br>
with an "id" attribute (I have a GroupType defined in my
custom schema).<br>
<br>
I can achieve the simple case, without the "id" attribute.
So I can see<br>
in the Admin Console that the User has several groups, which
I do with<br>
the following mapping :<br>
<br>
<attribute><br>
<ref>ri:groups</ref><br>
<inbound><br>
<expression><br>
<script><br>
<code><br>
[parse input and return array of string [a, b,<br>
c...]<br>
</code><br>
</script><br>
</expression><br>
<target><br>
<path>$user/extension/my:group</path><br>
</target><br>
</inbound><br>
</attribute><br>
<br>
Now I'm trying to map attributes for the group element<br>
($user/extension/my:group/@id)<br>
<br>
Has anyone tried this? Thanks for any input!<br>
<br>
BR/<br>
</div>
</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Deepak Natarajan<br>
Director<br>
<br>
Trilobyte Systems ApS<br>
<br>
Falkoner Alle 1, 3 Frederikinkatu 61A, 6th Floor<br>
2000 Frederiksberg Business Center Papula<br>
Denmark 00100 Helsinki<br>
Finland<br>
<br>
Tel : +45 29375068<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.trilobytesystems.com">http://www.trilobytesystems.com</a><br>
<br>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>