• State Verified Answer
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 96 subscribers
  • Views 2519 views
  • Users 0 members are here
Options
Related

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

daniel.storck
over 1 year ago

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

Parents
  • 0 over 1 year ago

    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.

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

    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,

  • 0 over 1 year ago in reply to Hanno Bunjes

    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

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

    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.

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

    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.

Children