Forum Discussion
Codeless Connect Framework (CCF) Template Help
jamos Sorry to hear that. The second trick that comes to my mind is to leverage the pagination attribute in your polling configuration. While not its intended purpose, you can use it to build the required date parameters with proper variable substitution.
"pollingConfig": {
"request": {
"apiEndpoint": "https://my.hostname.com/path/to/api/myEndpoint",
"httpMethod": "GET"
},
"queryParameters": {
"EventDates": "{_QueryWindowStartTime}"
},
"pagination": {
"type": "custom",
"paginationType": "linkHeader",
"link": "{_nextPageLink}",
"additionalQueryParameters": {
"EventDates": "{_QueryWindowEndTime}"
}
},
...
}
- The initial request will send the EventDates={_QueryWindowStartTime} parameter, which is correctly substituted from the queryParameters section.
- The pagination attribute is configured to add additionalQueryParameters to the next page request.
- By setting the pagination type to custom and the link to a placeholder ({_nextPageLink}), you effectively bypass the standard pagination logic.
- The additionalQueryParameters section will then append EventDates={_QueryWindowEndTime} to the URL, resulting in a single URL with both repeated parameters properly substituted.
Unfortunately, another dead end. I didn't see anything in the documentation to indicate pagination.additionalQueryParameters was an expected / accepted path, but I did try it. The section was completely ignored resulting in NO parameters other than the page size (which is also defined under the pagination path) being present in the constructed URL.
With that said, I also found that the pagination capabilities aren't going to be sufficient for some of the APIs I need to call since they only pass the current page and no next page number or token. This means CCF simply isn't going to be a viable solution for this project.
I do appreciate your time and suggestions, though!