<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">I think what we can possibly do is:<br>
      <br>
      1) Improve KeycloakTransactionManager to allow enlist with
      "priority" . Instead of methods:<br>
      <br>
      void enlist(KeycloakTransaction transaction);<br>
      void enlistAfterCompletion(KeycloakTransaction transaction);<br>
      <br>
      we will have single method:<br>
      <br>
      void enlist(KeycloakTransaction transaction, int priority);<br>
      <br>
      By default, JPA will enlist transaction with priority 10 and
      infinispan with priority 20 or something like that.<br>
      <br>
      This change will allow to enlist your transaction in your
      FederationProvider with exact priority. So you can choose whether
      the commit will happen  before JPA commit, or after JPA commit or
      even after infinispan commit etc.<br>
      <br>
      2) Make TxAwareLDAPUserModelDelegate class more generic and
      reusable for other federation providers<br>
      <br>
      Marek<span style="background-color:#e4e4ff;"><br>
        <br>
      </span>
      <pre style="background-color:#ffffff;color:#000000;font-family:'DejaVu Sans Mono';font-size:9.0pt;"></pre>
      On 11/12/15 10:50, Vlastimil Elias wrote:<br>
    </div>
    <blockquote cite="mid:566A9C53.1080401@redhat.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Hi,<br>
      <br>
      I use similar approach and problem is (at least I think) that
      local DB transaction is already commited when our code runs. It
      has two negative effects:<br>
      - if remote service call is successful you are not able to write
      anything locally as Jorge mentioned<br>
      - if remote service call fails local DB record is commited already
      and it is hard to implement correct error handling<br>
      <br>
      So I think User Federation SPI should be extended by exact method
      which allows atomic call of backend during user creation or update
      before local transaction is commited. I already created issue for
      it but not resolved yet <a moz-do-not-send="true"
        class="moz-txt-link-freetext"
        href="https://issues.jboss.org/browse/KEYCLOAK-1075">https://issues.jboss.org/browse/KEYCLOAK-1075</a><br>
      <br>
      Vlastimil<br>
      <br>
      <div class="moz-cite-prefix">On 10.12.2015 18:49, Jorge M. wrote:<br>
      </div>
      <blockquote
cite="mid:CAHEpHRLRHiqNAQUm0KJnCDrtMWp9ZNOPY5ffLDEfhbZJsRLSNg@mail.gmail.com"
        type="cite">
        <p dir="ltr">Hi,</p>
        <p dir="ltr">I think I'm in the right track now. I'm being able
          to call the webservice before commit. However, when the user
          is sucessfully created by the webservice, I need to update my
          local user to add a property with the external user id. How
          can I do that in the same transaction?<br>
          I'm trying to set the property on the managed delegate user
          model, but it has no effect.</p>
        <p dir="ltr">Thank you!</p>
        <div class="gmail_quote">On 9 Dec 2015 18:39, "Marek Posolda"
          &lt;<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
            href="mailto:mposolda@redhat.com">mposolda@redhat.com</a>&gt;

          wrote:<br type="attribution">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF">
              <div>On 09/12/15 19:33, Jorge M. wrote:<br>
              </div>
              <blockquote type="cite">
                <p dir="ltr">I'm developing a custom federation that
                  communicates with my user repository via webservices.
                  <br>
                  Probably this is a very strange scenario for a
                  federation but that's the unique way that I have to
                  communicate with the repository.</p>
                <p dir="ltr">My problem is that, as the webservices only
                  exposes methods such as createUser and updateUser, I'm
                  having problems with registrations and user profile
                  updates because I'm not being able to do atomic calls
                  to the webservice methods, with all the information
                  that I need.</p>
                <p dir="ltr">As far as I know, from the properties file
                  example and from the ldap federation source (probably
                  I'm missing something) it seems that the federation
                  api is intended to update and sync attribute by
                  attribute (Keycloak &lt;-&gt; Federation). <br>
                  Am i wrong? Do you suggest another approach? Should I
                  give up from having a federation that uses a
                  webservice?</p>
              </blockquote>
              You can use "transaction wrapper", which will allow you to
              store all the updates to user locally, but send the UPDATE
              request to your webservice later at transaction commit
              time. You may need to create custom transaction and enlist
              it with Keycloak TransactionManager. <br>
              <br>
              This is what we have for LDAP federation provider right
              now. See <span style="background-color:#e4e4ff">TxAwareLDAPUserModelDelegate.</span>
              <br>
              <br>
              Marek<br>
              <blockquote type="cite">
                <p dir="ltr">Thank you.</p>
                <br>
                <fieldset></fieldset>
                <br>
                <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
              </blockquote>
              <br>
            </div>
          </blockquote>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>