Creating imx-api library with ImxClient in One Identity Manager 9.1

Hello,

we have an custom API which was created with One Identity Manager v8 and has been configured with the ApiDesigner. We are now switching to One Identity Manager 9.1. I have changed the implementation so that our API Projects are now registered as a Plugin in the VisualStudio project. So far so good, the API is properly picked up by the ApiServer once loaded into the Database and requesting the custom endpoints works fine. But now we come to the Angular related part. In the past, we have used the imx-api library which was created by the ApiDesigner to make use of the custom models and to invoke the API requests with the respective autogenerated functions.

In 9.1 we have to use the ImxClient. According to the documentation, i can create the typescript client package with something like this:

ImxClient.exe compile-api /copyapi C:\...\imx-api-ccc.tgz /packagename imx-api-ccc

I expected to get a similar package as with the imx-api but there are all of our custom models / API endpoints missing. There are tons of Info messages saying:

Info: Endpoint GET ... was not found in code and deleted.

What does this mean and how can we get a client library similar to the imx-api in 8.2 ?

Best regards, Daniel

  • Okay i could make it work... but this is not really a user friendly approach. You have to make sure that the Custom API Plugin is available in the same directory as all of the other Module API Plugins, so that the ImxClient is able to pick it up. Unfortunately the documentation is also outdated when it comes to the ImxClient and its missing crucial details.

  • Former Member
    0 Former Member over 1 year ago in reply to daniel.storck

    Hi, Daniel, I'm struggling with this too. Could you please give more details as to what to do , what to place so the imxclient works? Reading the documentation (and I completely agree with you) it seems that you only need to run the imxclient command "as it is" and that will make it all.  

    Documentation (¿?) : 

    imxclient compile-api -N -W /copyapi imx-api-ccc.tgz /packagename imx-api-ccc


    Thanks!

  • Hi,

    so once you have implemented your Custom API as a plugin in Visual Studio, you should have a build CCC.CompositionApi.Server.Plugin.dll file. Just put it into your installation folder of One Identity Manager where the ImxClient.exe is located. Then you can run

    ImxClient.exe compile-api /copyapi C:\...\imx-api-ccc.tgz /packagename imx-api-ccc

    This will create a node package imx-api.ccc.tgz within the path you specified.

    You should see an info in during the build like "Info: Plugin assembly loaded: CCC.CompositionApi.Server.Plugin ..." then you know that your Custom API will be part of the client.

    As a sidenote:

    Parameter -W is not supported by the ImxClient.exe anymore and DO NOT USE parameter -N.

    Parameter -N prevents the creation of the node package, i have no idea why this is used in that example of the documentation because that's basically what our goal is.

  • Hi Daniel,

    Any API plugins you write must be present, otherwise the API compiler will simply not know about these APIs. Have you added the API plugin to software update?

    Can you elaborate on which steps were missing in the documentation (other than the fact that API plugins must be present) ? This would help us enhance the documentation.

    Thanks,

  • Hi Hanno,

    regard your first point)

    my expectation first was that the ImxClient picks up the API Plugin from the database. SoftwareLoading the Custom API Plugin is possible, thats what i did in the end. Unfortunately you cannot make use of the SoftwareLoaded package that you already have to do in order to deploy your API. The reason for that is that the Business API Server expects the file to be in bin\CCC.CompositionApi.Server.Plugin whereas you development/workstation installation expects it in the root folder. So you have to do 2 SoftwareLoads, one for deployment on the Business API Server and one for the development/workstation installation. I think the SoftwareLoad & AutoUpdate approach is not really suited for development and build purposes. It would be better if you could have an optional parameter for the ImxClient compile-api command in order to be able to setup a custom location of the Custom API Plugin. Similar to what you have as /plugin parameter for the ImxClient run-api command.

    regard your second point)

    i don't know where to start but in my opinion you need to have a very good knowledge in order to figure out what you actually have to do. E.g. the following is missing

    - How to run the api server with your custom build plugin -> run-api /plugin ... should be mentioned here especially to use it in Visual Studio

    - SoftwareLoad has to be done as /bin/CCC.CompositionApi.Server.Plugin.dll for the Business API Server, otherwise your .dll will end up in the wrong directory and your API is not available on the IIS

    - The ImxClient documentation is completely outdated, many commandline arguments of the doc are not available in the ImxClient v.91

  • Thanks for elaborating.

    We will provide more detailed description on how to upload an API plugin. You are correct in that the different file paths are required, and that is a bit difficult.

    I would argue that, if you have a custom location where you are storing your API plugin (bypassing the software update process) then you should copy this plugin DLL to the program directory before running compile-api. Loading a DLL from an arbitrary location on the file system is not a really good idea from a security standpoint, and we're going to remove that on the run-apiserver command.

  • Please test new documentation on someone who is not on your team. I can volunteer.

  • Former Member
    0 Former Member over 1 year ago in reply to daniel.storck

    Thanks Daniel, tested and working!

  •  thanks for your explanations. The part regarding /bin/ folder on API Server was crucial in my case here. I believe your comment is the only documentation available currently on this one.

      the complete topic on making custom API plugins working finally (also on integrating them into custom web), due to limited documentation is only possible by trial and error. Please enhance the documentation.