Highlighted
Respected Contributor.
Respected Contributor.
671 views

REST Driver with IBM Connections REST API

Hello guys,

I need to implement the connection between the REST Driver and the corresponding REST API from IBM Connections.

I read the REST Driver documentation understanding the behaviour and how it should work, but I have some doubts.

Firstly, I configured the connection data with the authentication to the API. Then, I filled up the Resources paragraph in the Subscriber configuration with the necessary URL's that are indicated in the IBM Connections REST API. Specifically I put those which I need, exactly these ones.

At this point, my main doubt is: How the driver knows by itself which URL needs, to create the <driver-operation-data> object with the correct data in order to perform the desired action through the IBM Connections API?:confused:

Thanks in advance,
Rodrigo
Labels (1)
0 Likes
7 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Re: REST Driver with IBM Connections REST API

rcano <rcano@no-mx.forums.microfocus.com> wrote:
>

Hello guys,
>
> I need to implement the connection between the REST Driver and the

corresponding REST API from IBM Connections.
>
> I read the 'REST Driver'

(https://www.netiq.com/documentation/idm45drivers/generic_rest/data/bv5810b.html)
documentation understanding the behaviour and how it should work, but I
have some doubts.
>
> Firstly, I configured the connection data with the authentication to the

API. Then, I filled up the Resources paragraph in the Subscriber
configuration with the necessary URL's that are indicated in the IBM
Connections REST API. Specifically I put those which I need, exactly
'these'
(https://www-10.lotus.com/ldd/appdevwiki.nsf/xpAPIViewer.xsp?lookupName=API+Reference#action=openDocument&res_title=Subscriber_management_services_bss&content=apicontent)
ones.
>
> At this point, my main doubt is: How the driver knows by itself which

URL needs, to create the <driver-operation-data> object with the correct
data in order to perform the desired action through the IBM Connections
API?:confused:
>
>


This is partially explained in the doc.
If I recall correctly it is a consequence of object class (in app namespace
post schema mapping) and and the operation type (add/modify/query/delete)


--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: REST Driver with IBM Connections REST API

On 7/18/2016 7:18 AM, Alex Mchugh wrote:
> rcano <rcano@no-mx.forums.microfocus.com> wrote:
>>

> Hello guys,
>>
>> I need to implement the connection between the REST Driver and the

> corresponding REST API from IBM Connections.
>>
>> I read the 'REST Driver'

> (https://www.netiq.com/documentation/idm45drivers/generic_rest/data/bv5810b.html)
> documentation understanding the behaviour and how it should work, but I
> have some doubts.
>>
>> Firstly, I configured the connection data with the authentication to the

> API. Then, I filled up the Resources paragraph in the Subscriber
> configuration with the necessary URL's that are indicated in the IBM
> Connections REST API. Specifically I put those which I need, exactly
> 'these'
> (https://www-10.lotus.com/ldd/appdevwiki.nsf/xpAPIViewer.xsp?lookupName=API+Reference#action=openDocument&res_title=Subscriber_management_services_bss&content=apicontent)
> ones.
>>
>> At this point, my main doubt is: How the driver knows by itself which

> URL needs, to create the <driver-operation-data> object with the correct
> data in order to perform the desired action through the IBM Connections
> API?:confused:
>>
>>

>
> This is partially explained in the doc.
> If I recall correctly it is a consequence of object class (in app namespace
> post schema mapping) and and the operation type (add/modify/query/delete)


The idea in REST is that there were sort of two approaches.

1) An endpoint URL for each object class, and then an additional part of
the URL for each operation. So https://server/users/add or
https://server/groups/delete

2) Then a more elegant solution where a single end point per object
class is used, https://server/users and then the HTTP action you take,
GET, PUT, DELETE, PATCH map to query, add, delete, and modify actions.

So the shim tries to map the endpoint to an object class, in your config
first, then you goof around it with you as you need it in your policies..

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Re: REST Driver with IBM Connections REST API

geoffc;2434692 wrote:
On 7/18/2016 7:18 AM, Alex Mchugh wrote:
> rcano <rcano@no-mx.forums.microfocus.com> wrote:
>>

> Hello guys,
>>
>> I need to implement the connection between the REST Driver and the

> corresponding REST API from IBM Connections.
>>
>> I read the 'REST Driver'

> (https://www.netiq.com/documentation/idm45drivers/generic_rest/data/bv5810b.html)
> documentation understanding the behaviour and how it should work, but I
> have some doubts.
>>
>> Firstly, I configured the connection data with the authentication to the

> API. Then, I filled up the Resources paragraph in the Subscriber
> configuration with the necessary URL's that are indicated in the IBM
> Connections REST API. Specifically I put those which I need, exactly
> 'these'
> (https://www-10.lotus.com/ldd/appdevwiki.nsf/xpAPIViewer.xsp?lookupName=API+Reference#action=openDocument&res_title=Subscriber_management_services_bss&content=apicontent)
> ones.
>>
>> At this point, my main doubt is: How the driver knows by itself which

> URL needs, to create the <driver-operation-data> object with the correct
> data in order to perform the desired action through the IBM Connections
> API?:confused:
>>
>>

>
> This is partially explained in the doc.
> If I recall correctly it is a consequence of object class (in app namespace
> post schema mapping) and and the operation type (add/modify/query/delete)


The idea in REST is that there were sort of two approaches.

1) An endpoint URL for each object class, and then an additional part of
the URL for each operation. So https://server/users/add or
https://server/groups/delete

2) Then a more elegant solution where a single end point per object
class is used, https://server/users and then the HTTP action you take,
GET, PUT, DELETE, PATCH map to query, add, delete, and modify actions.

So the shim tries to map the endpoint to an object class, in your config
first, then you goof around it with you as you need it in your policies..


Thanks for your replies,

In this case, IBM API is using the 2nd option more or less. I understood that the driver maps the operation to one of the resources defined in the subscriber configuration for every schema object. The fact that are confusing me is that I have more than one operation using the same endpoint structure and the same HTTP action.

For example, I have these two URL's in the IBM API:

Service: Suspend subscriber (a user in IBM Connections)
URL: /resource/subscriber/<id>
HTTP action: POST
Operation: Add ?¿

Service: Unsuspend subscriber
URL: /resource/subscriber/<id>
HTTP action: POST
HTTP Header: x-operation: unSuspendSubscriber
Operation: Add ?¿

The unique difference between them are the HTTP header needed in the second one. I don't know if I mapped correctly the operation type but, I saw in the doc that the POST method is an Add in the default handler configuration. In this case, how the driver will know which is the correct one to perform either operations?


By another hand, I was looking carefully the policies in the driver and I concluded that the clue and the magic happens on the output policy "XDSToJSON". I guess that I should modify these one to achieve what I want. Is that correct?

I hope I made myself clear,
Rodrigo
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: REST Driver with IBM Connections REST API

On 7/18/2016 3:46 PM, rcano wrote:
>
> geoffc;2434692 Wrote:
>> On 7/18/2016 7:18 AM, Alex Mchugh wrote:
>>> rcano <rcano@no-mx.forums.microfocus.com> wrote:
>>>>
>>> Hello guys,
>>>>
>>>> I need to implement the connection between the REST Driver and the
>>> corresponding REST API from IBM Connections.
>>>>
>>>> I read the 'REST Driver'
>>>

>> (https://www.netiq.com/documentation/idm45drivers/generic_rest/data/bv5810b.html)
>>> documentation understanding the behaviour and how it should work, but

>> I
>>> have some doubts.
>>>>
>>>> Firstly, I configured the connection data with the authentication to

>> the
>>> API. Then, I filled up the Resources paragraph in the Subscriber
>>> configuration with the necessary URL's that are indicated in the IBM
>>> Connections REST API. Specifically I put those which I need, exactly
>>> 'these'
>>>

>> (https://www-10.lotus.com/ldd/appdevwiki.nsf/xpAPIViewer.xsp?lookupName=API+Reference#action=openDocument&res_title=Subscriber_management_services_bss&content=apicontent)
>>> ones.
>>>>
>>>> At this point, my main doubt is: How the driver knows by itself which
>>> URL needs, to create the <driver-operation-data> object with the

>> correct
>>> data in order to perform the desired action through the IBM

>> Connections
>>> API?:confused:
>>>>
>>>>
>>>
>>> This is partially explained in the doc.
>>> If I recall correctly it is a consequence of object class (in app

>> namespace
>>> post schema mapping) and and the operation type

>> (add/modify/query/delete)
>>
>> The idea in REST is that there were sort of two approaches.
>>
>> 1) An endpoint URL for each object class, and then an additional part of
>> the URL for each operation. So https://server/users/add or
>> https://server/groups/delete
>>
>> 2) Then a more elegant solution where a single end point per object
>> class is used, https://server/users and then the HTTP action you take,
>> GET, PUT, DELETE, PATCH map to query, add, delete, and modify actions.
>>
>> So the shim tries to map the endpoint to an object class, in your config
>> first, then you goof around it with you as you need it in your
>> policies..

>
> Thanks for your replies,
>
> In this case, IBM API is using the 2nd option more or less. I understood
> that the driver maps the operation to one of the resources defined in
> the subscriber configuration for every schema object. The fact that are
> confusing me is that I have more than one operation using the same
> endpoint structure and the same HTTP action.
>
> For example, I have these two URL's in the IBM API:
>
> *Service:* Suspend subscriber (a user in IBM Connections)
> *URL:* /resource/subscriber/<id>
> *HTTP action:* POST
> *Operation:* Add ?�
>
> *Service:* Unsuspend subscriber
> *URL:* /resource/subscriber/<id>
> *HTTP action:* POST
> *HTTP Header:* x-operation: unSuspendSubscriber
> *Operation:* Add ?�
>
> The unique difference between them are the HTTP header needed in the
> second one. I don't know if I mapped correctly the operation type but, I
> saw in the doc that the POST method is an Add in the default handler
> configuration. In this case, how the driver will know which is the
> correct one to perform either operations?
>
>
> By another hand, I was looking carefully the policies in the driver and
> I concluded that the clue and the magic happens on the output policy
> "XDSToJSON". I guess that I should modify these one to achieve what I
> want. Is that correct?


So yes and no.

Here, you would have the user, add event, mapped to these endpoints.
Assuming all you are doing is supsend/unsuspend via this driver. If you
are doing user creates through this same driver it would be more complex

The key difference is that you need an extra header in the unSuspend
case you need to add. I know the SOAP shim has the ability to add new
headers to the event. I forget if the REST shim has it as well.

I am pretty sure the Driver Config has parameters to allow that in
general cases. I cannot recall offhand, if you can add some
driver-operation-data that adds a header to the POST event.

0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Re: REST Driver with IBM Connections REST API

geoffc;2434714 wrote:
On 7/18/2016 3:46 PM, rcano wrote:
>
> geoffc;2434692 Wrote:
>> On 7/18/2016 7:18 AM, Alex Mchugh wrote:
>>> rcano <rcano@no-mx.forums.microfocus.com> wrote:
>>>>
>>> Hello guys,
>>>>
>>>> I need to implement the connection between the REST Driver and the
>>> corresponding REST API from IBM Connections.
>>>>
>>>> I read the 'REST Driver'
>>>

>> (https://www.netiq.com/documentation/idm45drivers/generic_rest/data/bv5810b.html)
>>> documentation understanding the behaviour and how it should work, but

>> I
>>> have some doubts.
>>>>
>>>> Firstly, I configured the connection data with the authentication to

>> the
>>> API. Then, I filled up the Resources paragraph in the Subscriber
>>> configuration with the necessary URL's that are indicated in the IBM
>>> Connections REST API. Specifically I put those which I need, exactly
>>> 'these'
>>>

>> (https://www-10.lotus.com/ldd/appdevwiki.nsf/xpAPIViewer.xsp?lookupName=API+Reference#action=openDocument&res_title=Subscriber_management_services_bss&content=apicontent)
>>> ones.
>>>>
>>>> At this point, my main doubt is: How the driver knows by itself which
>>> URL needs, to create the <driver-operation-data> object with the

>> correct
>>> data in order to perform the desired action through the IBM

>> Connections
>>> API?:confused:
>>>>
>>>>
>>>
>>> This is partially explained in the doc.
>>> If I recall correctly it is a consequence of object class (in app

>> namespace
>>> post schema mapping) and and the operation type

>> (add/modify/query/delete)
>>
>> The idea in REST is that there were sort of two approaches.
>>
>> 1) An endpoint URL for each object class, and then an additional part of
>> the URL for each operation. So https://server/users/add or
>> https://server/groups/delete
>>
>> 2) Then a more elegant solution where a single end point per object
>> class is used, https://server/users and then the HTTP action you take,
>> GET, PUT, DELETE, PATCH map to query, add, delete, and modify actions.
>>
>> So the shim tries to map the endpoint to an object class, in your config
>> first, then you goof around it with you as you need it in your
>> policies..

>
> Thanks for your replies,
>
> In this case, IBM API is using the 2nd option more or less. I understood
> that the driver maps the operation to one of the resources defined in
> the subscriber configuration for every schema object. The fact that are
> confusing me is that I have more than one operation using the same
> endpoint structure and the same HTTP action.
>
> For example, I have these two URL's in the IBM API:
>
> *Service:* Suspend subscriber (a user in IBM Connections)
> *URL:* /resource/subscriber/<id>
> *HTTP action:* POST
> *Operation:* Add ?�
>
> *Service:* Unsuspend subscriber
> *URL:* /resource/subscriber/<id>
> *HTTP action:* POST
> *HTTP Header:* x-operation: unSuspendSubscriber
> *Operation:* Add ?�
>
> The unique difference between them are the HTTP header needed in the
> second one. I don't know if I mapped correctly the operation type but, I
> saw in the doc that the POST method is an Add in the default handler
> configuration. In this case, how the driver will know which is the
> correct one to perform either operations?
>
>
> By another hand, I was looking carefully the policies in the driver and
> I concluded that the clue and the magic happens on the output policy
> "XDSToJSON". I guess that I should modify these one to achieve what I
> want. Is that correct?


So yes and no.

Here, you would have the user, add event, mapped to these endpoints.
Assuming all you are doing is supsend/unsuspend via this driver. If you
are doing user creates through this same driver it would be more complex

The key difference is that you need an extra header in the unSuspend
case you need to add. I know the SOAP shim has the ability to add new
headers to the event. I forget if the REST shim has it as well.

I am pretty sure the Driver Config has parameters to allow that in
general cases. I cannot recall offhand, if you can add some
driver-operation-data that adds a header to the POST event.


Well, I made few test with the driver and the Custom Resource Handlers.

Firstly, I defined this Custom Handler in the configuration:

Entitle Subscriber
URL: /api/bss/resource/subscriber/<subscriber_id>/subscription/<subscription_id>
*HTTP action:* POST
*Operation:* Add

Then, I modified the XDSToJSON policy to populate the <url-token> element with a random subscriber_id and subscription_id value. When I triggered and event throught the Subscriber channel of the driver, I saw how it worked and the driver shim has populated the tokens in the URL call correctly.

Viewing this behaviour, i tried to define another "POST Add" Custom Handler, exactly the "Add Subscriber":

Add Subscriber
URL: /api/bss/resource/subscriber?suppressEmail=true
*HTTP action:* POST
*Operation:* Add

Then, I disabled the subscriber_id and the subscription_id <url-token> population and added the necessary data to create a new subscriber through the REST call. With that test I wanted to check if the driver shim would select the correct Resource Handler. But it failed, the driver selected the Previous Custom Handler of Entitle Subscriber instead of the Add Subscriber.

I guess that the only way to make this works is generate all the URL beyond "/api/bss/resource/subscriber/" in the XDSToJSON policy, but I would need a clue to know which operation should be performed.

What do you think guys?

Thanks in advance,
Rodrigo Cano
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: REST Driver with IBM Connections REST API

I think you should think more carefully about your model and how it can map
to XDS in the way the driver shim wants.

For example subscriber and subscription might make more sense as two
different object classes, which might simplify your implementation
somewhat.

--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...

Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Highlighted
Respected Contributor.
Respected Contributor.

Re: REST Driver with IBM Connections REST API

alexmchugh;2435113 wrote:
I think you should think more carefully about your model and how it can map
to XDS in the way the driver shim wants.

For example subscriber and subscription might make more sense as two
different object classes, which might simplify your implementation
somewhat.

--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...


Indeed, subscriber and subscription are two different object classes. Only I need the subscription_id for this REST call. In fact, all the subscription_id codes will be populated via a driver variable, because them are unique and doesn't change.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.