Getting data from API - but API parameter is data from a recordType

Hello:

I need to retrieve data from an external API which requires a parameter (ProductID).  The values for ProductID reside in an application recordType table and has to be passed to the integration.  So, the expression called to populate another recordType to store data from the API has a query.  However, I keep getting this error.  Any suggestions on how to resolve this issue?

Thank you.

Ma

  Discussion posts and replies are publicly visible

Parents Reply Children
  • If I understand the documentation correctly, it is the Record Data Source that has the batchNumber as the rule-input.  However, in my case, the Record Data Source has the batchNumber as the rule-input but I have to use the rule-input to obtain the list of IDs to process.  The underlying API/integration doesn't have a 'startIndex' as the parameter.  The API/integration parameter is the list of IDs.

  • +1
    Certified Lead Developer
    in reply to MaNa

    Try to make a step backwards. A service backed record is just using your expression to pass the batch number and get a datasubset returned. This is all your expression has to do. And it does not matter how it is doing it. You can do any number of web service calls to achieve this.

    In the record source configuration, you just call your integration passing the batch number as a rule input. Inside that integration object, you call your existing expression to get the list of IDs by passing the batch number.

    In the screenshot you write "Need a list of IDs for current batchNumber". What do you mean? Isn'1 that the job of this first expression? Can't you just pass that list of IDs stored in local!ListToProcess into "rule!FST_getFull...something..."?

  • I think I have it working - thanks for your help! 

    I was not putting the expression in the right place - had rule!input expression mixed up with query parameter expression.

  • Guess, I was wrong.  The RecordType synch failed :( .  Integration works.  They Record Source expression works - they both returns values as expected.  But configure data sources doesn't work. 

    Any suggestions on how to load 10300 records?

    Thanks.

    This works - returns 25 records from the integration.

  • 0
    Certified Lead Developer
    in reply to MaNa

    Syncing in batches is described in the documentation link I posted above.

    Do you use any of the functions mentioned in the error message?

  • I use a!queryRecordType to retrieve the productIDs from the table with the productIDs.  The documentation link talks about how to use batchNumber to calculate 'pageSize' / 'startIndex' but this API parameter requires a list of productIDs.  I have over 10,000 productIDs in the application database and for each productID, I have to call the API to get current product details.

    In the last attempt, I set one of the integration query parameters to retrieve the productIDs based on the batchNumber.  The integration worked fine and the RecordSource expression that calls the integration worked.  However, when I tried to synch the data, it gives the error about not using a!queryRecordType

  • 0
    Appian Employee
    in reply to MaNa

    Can you just try a list of 1000 product IDs (even if some of those don't have corresponding products)? Then you don't have to do any query to find the relevant product IDs from Appian. For instance, just make your batch 1 use values 1...1000, and then try 1001...2000, etc. Even if the first batch only returns a handful of products, it will still work.

  • We tried your suggestion but we were unable to retrieve all the information we needed.  The productIDs start at 321,358 and goes all the way to 2,512,370.  We were able to extract information up to 2,273,113 but the rest weren't extracted.  Since there is a rate limit on accessing API, we did adjust the rate using "Add rate limit".

    In this case, the ProductIDs are numerical, so we could use this strategy, what approach should we use if the ProductIDs were Text?

    Thanks.

  • 0
    Appian Employee
    in reply to MaNa

    Can you provide more information about what didn't work? I didn't quite follow which ones were missing.

    You're correct that this method would only apply to numerical IDs. I think it would depend on what format you expect the text IDs to be whether you could do a similar strategy or not.