Integrationpublic

Integration

Get Involved. Join the Conversation.

This is a public Forum  public

Topic

    Frank Brink
    Failed instances with heading "Primary Identifier:...
    Topic posted November 13, 2019 by Frank BrinkRed Ribbon: 250+ Points, tagged Integration, REST 
    16 Views, 8 Comments
    Title:
    Failed instances with heading "Primary Identifier: undefined" in the monitoring/tracking area
    Summary:
    Failed instances with heading "Primary Identifier: undefined" in the monitoring/tracking area next to a succesful instance for the same integration of type basic routing
    Content:

    The launch of an integration of type basic routing result next to a succesful instance also in a failed insatnce with the following heading:
    Primary Identifier: undefined | 3200186 (latter is the instance id)
    Note that there is also a succesful instance with heading:
    name: Paco Instance ID: 4000090
    Hello World Map Data Invoke | 1.1.0 Completed
    Where does this failed instance for the Hello World Map Data Invoke integration coming from - why are there two instances - one succesful and one failed?
    This can be easy reproduced with the deafult sample (Hello World Map Data Invoke integration) you receive when you create an instance: 
    I can also reproduce it with my custom integrations of type basic routing: there are always two instances: one failed and one succesful
    How to explain this during a demonstration of the prroduct?

    Version:
    OIC Version 19.3.3.0.0 (190924.1600.31521)
    Image:

    Comment

     

    • Frank Brink

      Please note that I do have defined one ore more business Identifiers in the tracking menu option in the integration tab - hence the heading at the successful instance

      As far as I know you can only define business identifiers on the request parameters

      So if this failed instance is coming from the reply where can you define tracking on the reply?

       

    • Hemanth Lakkaraju

      This is how Basic Authentication works! - Request - Challenge - Response (RCR) way. The client usually sends Unauthenticated request for which Server sends a 401 challenging the request and then client sends authenticated request. Since there are 2 calls happening here, 2 entries are seen. If you choose preemptive authentication, then client sends the authenticated request at first call.

      You can easily see the behaviour in SoapUI logs when you make the call.

      Note:  This duplicate instance creation is handled in next releases!

      • Frank Brink

        I am not aware that I have send 2 calls - as far as I know I only perform one call - and within SOAPUI I only see one response.

        Is there a way you can recognize/follow this "2 calls behavior" within SOAPUI in the log tab?

        • Hemanth Lakkaraju

          Open SoapUI log tab before you hit the send request button - that will show you the 2 calls made. If you set preemptive-auth, you see only 1 request.

          • Frank Brink

            Thx - the same suggestion came from MOS - sorry missed your valuable input - but again thx for your effort - issue solved!

    • Rajan Modi

      You are correct - in "basic routing"/"Map Data" pattern, only request parameters can be used for tracking.  In Orchestration, one can use assign steps to use response payload to update tracking variables 2 and 3.

      Btw, how are you invoking this integration?  Looks like two requests are being received for every call made.

      • Frank Brink

        I use SOAPUI to invoke my basic routing integration - and within SOAPUI I only see one response - So I have no idea where this second call is coming from

    • Frank Brink

      Just now received a solution from MOS: change the basic authentication within SOAPUI to pre-emptive see uploaded image

      Now only the succesful instance is displayed!

     

    community forum