<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><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.03050501.09040000@trilobytesystems.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 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:part2.04010409.09020809@trilobytesystems.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 class="moz-txt-link-freetext" href="http://www.trilobytesystems.com">http://www.trilobytesystems.com</a><br>
<br>
<br>
</div>
</body></html>