Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
4 replies Latest Post - ‏2013-03-22T14:31:23Z by yn2000
SystemAdmin
SystemAdmin
9855 Posts
ACCEPTED ANSWER

Pinned topic Reading Supporting Data on a service using Javascript from Workflow

‏2013-03-21T01:09:08Z |
Hello All, I have a requirement that when the Person entity is being created, I need to refer to the supporting data(a group entry) on certain service and read one of the attribute on the service-group. For Example, I have created a service in ITIM that hold all the locations in my organizations. This service has multiple groups as supporting data. Each of this group defined a location name and the corresponding location ID.

When a Person is being created, Requestor will provide the Location name on the person form. The requestor will not provide the location code. So I need to refer to the Groups on the service, lookup the correct group entry with the Location name entered and fetch the corresponding LocationCode.

I did not find a javascript extension to read the Service-Group information in the workflows. If you have already attempted this, could you please help me with some information?
Updated on 2013-03-22T14:31:23Z at 2013-03-22T14:31:23Z by yn2000
  • SystemAdmin
    SystemAdmin
    9855 Posts
    ACCEPTED ANSWER

    Re: Reading Supporting Data on a service using Javascript from Workflow

    ‏2013-03-21T07:49:47Z  in response to SystemAdmin
    You will have to either use the groups APIs directly (not recommended) or wrap them in a JavaScript extension.

    Go to the examples folder on your ITIM system and check the samples available there.

    Basically you can get the service DN via Javascript - from there you can get the group via a groupSearch and the groupEntity using the lookup() method. If you need any data from the group you can get from the groupEntity.

    HTH

    Regards
    Franz Wolfhagen
  • yn2000
    yn2000
    1086 Posts
    ACCEPTED ANSWER

    Re: Reading Supporting Data on a service using Javascript from Workflow

    ‏2013-03-21T21:17:16Z  in response to SystemAdmin
    If you have read many of my posts, I tend not to read the requirement thoroughly. This could be one of them.
    It sounds like that you are looking a method to show the Location name, but storing the Location ID, which is a common practice in the Design Form, but you are looking for a solution in the operational workflow modification??? Do I miss something?

    Rgds. YN.
    • SystemAdmin
      SystemAdmin
      9855 Posts
      ACCEPTED ANSWER

      Re: Reading Supporting Data on a service using Javascript from Workflow

      ‏2013-03-22T06:23:23Z  in response to yn2000
      yn2000, this is not exactly what I am looking for. I kind of need the Location name and the code as well. Not just limiting to this, I might want to read more attributes about the location that could be available as a group entry on a service. It would be great if you could put some comments about this.
      • yn2000
        yn2000
        1086 Posts
        ACCEPTED ANSWER

        Re: Reading Supporting Data on a service using Javascript from Workflow

        ‏2013-03-22T14:31:23Z  in response to SystemAdmin
        If I read the requirement correctly, you are looking a method to get a value in an attribute in the group entity and would like to store it in the person entity. For example, there is Location ID: 123; Location Name: North Building 1A; Floor Level: Level 2. You want to search Location ID: 123 and some how populate Location Name and Floor Level values in the person entity.

        Yup, I never do it, because I never deal with this type of requirement.

        In most cases, when I am dealing with a group entity, I am dealing only with group ID and group Name. I put the user in the group ID membership and done. The group Name is just for the display. If the target application (target resource) needs additional attribute, then the target application is the one that should be querying from the group entity (repository). I think that is the basic rule of designing a 'relational database', because when the group entity changes, such as Location ID: 123 changed to have Floor Level: M, then you are liable to fix all incorrect data in the person entity.

        So, if you insist solving this requirement without redesigning it, then I guess you have to follow what Franz has posted... the 'non recommended' API.

        Rgds. YN.