4 Replies Latest reply on Oct 20, 2014 3:52 AM by lvornholt

    missing meta data information for ESF Java SKD

    lvornholt

      Hi Ryan Rutan, hi David Nicholls,


      The first steps are done. The example works fine ( Java SDK - We try to set up the example ESP ) thanks again for helping us. Our own ESP stores the first documents (attachments and files) in Documentum.


      We want to implement a kind of SSO to login in to Documentum to save the document with the user context (creator) and a user session - we will avoid to use a documentum system user. If the user create a file in jive the meta data "creator" is set - but if we create a document and the attachement is send to our ESP the creator name is missing (only contentType and fileName are set).


      Do we have to configurate which meta data are send?

      How we can get the user name who create the document or file in jive?


      Thanks

      Lars

        • Re: missing meta data information for ESF Java SKD
          david.nicholls

          Hi Lars Vornholt,

           

          If you add the following parameter to the upload method signature :

           

          @HeaderParam(IMPERSONATE_HEADER_NAME) String impersonateHeader,

           

          e.g.

           

          @POST

              @Path("/{folder}/upload")

              @Consumes(MediaType.MULTIPART_FORM_DATA)

              @Produces(MediaType.APPLICATION_JSON)   

              public Response upload(

                      @HeaderParam(HttpHeaders.AUTHORIZATION) String authorization,

                      @HeaderParam(IMPERSONATE_HEADER_NAME) String impersonateHeader, ....)

          This will then give you the user that you are to impersonate.

           

          However there is more to do to be able to get the user from this impersonateHeader, this is just some sample code I used to try it :

           

           

          protected String getImpersonateUser(String impersonateHeader) {

            byte[] bytes = Base64.decodeBase64(impersonateHeader);

           

            String json = new String(bytes);

            ExStorageUserEntity jiveImpersonate = convertImpersonation(json);

           

            // There seems to be some quirk where sometimes the data is sent with userMappingValue and sometimes just mappingValue.

            if (jiveImpersonate != null && jiveImpersonate.getUserMappingValue() != null) {

            log.info("User [" + jiveImpersonate.getUserMappingValue() + "]");

            return jiveImpersonate.getUserMappingValue();

            } else if (jiveImpersonate != null) {

            JiveUserEntity jiveImpersonate2 = convertImpersonationOverride(json);

            log.info("User [" + jiveImpersonate2.getMappingValue() + "]");

            return jiveImpersonate2.getMappingValue();

            }

           

            return null;

            }

           

           

          protected ExStorageUserEntity convertImpersonation(String json) {   

            try {

            ExStorageUserEntity jiveImpersonate = new ObjectMapper().readValue(json, ExStorageUserEntity.class);

            return jiveImpersonate;

            } catch (JsonParseException e) {

            log.error("Failed to convert JSON to object due to : " + json, e);

            } catch (JsonMappingException e) {

            log.error("Failed to convert JSON to object due to : " + json, e);

            } catch (IOException e) {

            log.error("Failed to convert JSON to object due to : " + json, e);

            }

              return null;

              }

           

          With these two methods you can see how this impersonateHeader is made of a JSON object (ExStorageUserEntity). This entity (in case you don't have it) is made up of the following 3 parameters:

           

          •     String userMappingOption;
          •     String userMappingValue;
          •     String displayName;

           

          This will return the mapped user (for the file storage provider it is configured to map via email, therefore this will give you the user's email address.

           

          Hope this helps

           

          Dave

            • Re: Re: missing meta data information for ESF Java SKD
              lvornholt

              Hi David Nicholls

               

              thanks for the answer. I try to integrate integrate and test your hints. I have two questions

               

              - Could you give me a hint. What is the name of the 'IMPERSONATE_HEADER_NAME' Header? I try to get the header names by wireshark but I was not able to find a header that fits.

              - I your example you have '@Path("/{folder}/upload"'@Path("/{folder}/upload")')' I find this without upload. The reason I ask is, if I got more Information about the file/attachement context (e.g. Name of the place or group) we could create rules for the path in Documentum. So we do not have to store all documents in the same Folder (at this Moment one Folder for a Workspace ID).

               

              Thanks a lot and I hope you have much fun on Jive world - hope next time I was also able to join.

               

              Lars

               

               

                • Re: Re: missing meta data information for ESF Java SKD
                  david.nicholls

                  Hi Lars Vornholt,

                   

                  That was a mistake missing that key information off sorry :

                   

                  protected static final String IMPERSONATE_HEADER_NAME = "X-IMPERSONATE-MAPPING";

                   

                  As for more information during file upload.  By its nature file upload can only upload the binary data according to the HTTP protocols.  However the idea is that you can choose to put the information in the URL as path parameters.  For example if you wanted the group name then when you register a group with the ESP it could add /{group-name}/upload to the URLs for accessing and uploading the data.  Thus whenever you access or upload files to these URLs it would pass this data.  The only thing this does not work for is the current user, which can be obtained from the header.

                   

                  Therefore you could change the FileStorageResponseResourceWrapper to pass back URLs with whatever data you would need for the operations, then whenever the operations are executed the URL will tell you the information you need, e.g. group name.

                   

                  Hope that helps

                   

                  Dave