IBM Verify

I am not sure I understand your questions fully - but let me try to give some answers...

When you are doing a REST call it is not a given what the REST server is returning to you - it may give you a very short "200" answer (OK) or it may return data to you - that has nothing to do with SDI but only with the REST API implementation.

If you are doing an ADD via an HTTPClient connector POST action you will get a response - that response may or may not contain what you need - here is what I do get the response : 

	//Perform call
	httpReply = myHttpConn.queryReply(httpcall);
	//return the JSON
	return(httpReply.getString("http.bodyAsString"));

basically this means that the json response you need to parse in the http.bodyAsString attribute on the response Entry.

If that does not contain what you need you must do another call to find/get you data record and add that the entry in your putEntry()  - you should be able to do that utilizing your connectors findEntry() with a SearchCriteria...

I do not know if this helps you - but this is how I would do it...

Hi Franz, 

thanks for your reply.
I've correctly parse the response and I've mapped these values on InputMap of CallReply component. 

the log of the TDI component is this:

When ADD operation has been closed successfully by connector, I'm searching a way to send this result:

http.bodyAsString = {"@odata.context":"https://mycompany-amc-stg.cloud.com/api/odata/$metadata#organizationalunits(RecId,Name)","@odata.count":1,"value":[{"RecId":"30BF214FCBB64ADBB7773214240115DC","Name":"Unknow"}]},erICMDBemployeelocationvalid = 8A74E89F401840AAA4F2194FBCB56A70,erICMDBdepartmentvalid = 0B640649A828499098D26A8FA55FF797,erICMDBstatus = Active,erICMDBfirstname = Saeed,erICMDBnetworkusername = TEST-AbdlajadS@mycompany.it,objectclass = erTDICustomAccount,erICMDBlastname = Abdolnejad,erICMDBloginidname = TEST-AbdlajadS@mycompany.it - Saeed Abdolnejad,erICMDBemployeelocation = City,erICMDBrecid = B96CD6BECAE541BD9B0016454520089F,erICMDBorgunitlinkrecid = 30BF214FCBB64ADBB7773214240115DC,$dn = eruid=TEST-AbdlajadS@mycompany.it,eruid = B96CD6BECAE541BD9B0016454520089F,ericmdbidentityid = abb0336d-fc60-4030-a35c-7f332d5be8df,erpassword = *****,eraccountstatus = 0,erICMDBloginid = TEST-AbdlajadS@mycompany.it,erICMDBprimaryemail = TEST-AbdlajadS@mycompany.it,erICMDBorganizationalunit = Unknow,erCMDBcontactid = d37917cd-7919-f011-b8af-0022489add7f,erICMDBdepartment = Adm}

to SVG.where using ResponseRule I can update the Account attributes on SVG, because some data are generate by SVG when the ADD operation starts and some data are generated by the target when the account is successfully created.

As you refer to a response rule I am assuming this is the IGI component - not ISVG/ISIM ? 

I am not an expert in IGI but AFAIK when an ADD operation is performed in an adapter that will return back to brokerage/ISVG what is in the work entry - you may need to ensure that OP codes of the attribute and attribute values are correctly set. 

But how this is then supposed to be processed in IGI I have no idea - my recommendation is to verify that the data IS returned by the adapter to brokerage and then raise a case to get an understanding of how that should be detected in event queues.

Hello, 

If this is a custom adapter and you want to return a field/attribute that generated on target during add operation, you have to use dispatcher parameters and work entries to achieve this. It doesn't matter it's IGI or ISIM this is a dispatcher feature. 

Have you checked custom adapter development guide? https://www.ibm.com/support/pages/node/6372574 -> Part number M0D47EN If you haven't It's good practice to read it beforehand. 

There is one very specific example in it, I think it was in assembly line section, that examples how to do this. Here is that section ;

Returning Implicit Attributes

On some resources, after an add operation, values of attributes that were not in the add request are set to some default by the resource itself. To return these attributes to ITIM, include them in the return entry and set the attribute operation to ATTRIBUTE_ADD and attribute value operation to AV_ADD. For example,

retWorkAttribute.addValue(retLookupAttr.getValue(j));

retWorkAttribute.setOper(Packages.com.ibm.di.entry.Attribute.ATTRIBUTE_ADD); retWorkAttribute.setValueOper(j,Packages.com.ibm.di.entry.AttributeValue.AV_ADD);

 Since your target operates with web services,  you have to parse your json/response to work attributes any way, after you achieve that you can add this to a hook and return any extra attributes that you didn't sent but target generated. 

Hope it helps. 

Thanks for pointing out the correct documentation - I could not remember where it was - but this is the correct example.

The adapter guide may feel somewhat difficult to read - I always jokes that it is not understandable until you have finished you first adapter :-)  

Thanks Franz and Ali,

the Ali's suggestion works perfectly. My first custom adapter is finally completed.

In the CallReply connection I added in the CallReply_ok:

Thanks for the confirmation - I hope it will work well for you !