Handle ticket search with Structured Data Analysis

hey Andrew! i’m curious how you are controlling the pagination? is that in the API call or a control in a compound action?

would you be able to share redacted screenshot(s) of your plugin and/or compound action that’s running the API call? lastly: i’m assuming you’ve checked the logs when the plugin runs to confirm how the API is responding, any clues there ?

For the pagination, in the search action I have a offset parameter that is being passed. I am then using compound action to loop on the action 5 times. Here is the yaml:

steps:
    - script:
        output_key: temp_array
        code: |
            return [i for i in range(5)]
        input_args: {}
    - for:
        each: item
        steps:
            - action:
                action_name: Ticket_Search
                input_args:
                    offset: (item_index) * 100
                    createdTimeGTE: data.createdTimeGTE
                    createdTimeLT: data.createdTimeLT
                    email: meta_info.userEmail
                    requesterId: data.requesterId
                    statusId: data.statusId
                output_key: Ticket_Search_output
        index: item_index
        in: data.temp_array
        output_key: Ticket_Search_output_iterated
    - return:
        output_mapper:
            requests:
                EVAL():
                    expression:
                        flatrequests.$FILTER(item => item)
                    args:
                        flatrequests:
                            FLATTEN(): 
                                data.Ticket_Search_output_iterated.$FILTER(item => item).$MAP(item => item.Ticket_Search_output.data)

Having it stop running if there wasn’t data returned gave me bad results when flattening, so I didn’t add that logic this time.

For the logs, it is returning values properly and there is no error, but it is running the plugin many times, each time getting the same ticket data.

Here are screenshots of the plugin where the decision policy is to optionally collect a user to search on as well. Content activity is “Take the ticket data from {{ticket_search}}. Filter it and format it based upon the user's {{search_description}}.” Conversation Process description is “Search for tickets based upon the status, requestor, and created time.”

For the logs, it is returning values properly and there is no error, but it is running the plugin many times, each time getting the same ticket data.

when you say getting the same ticket data each time, do you mean the response is exactly identical for each call? maybe the offset arg is not functioning properly so the for loop is not actually accessing the next index? have you confirmed that the offset value is different for each call?

also, i’m curious of the approach to create a manual 5-time maximum to loop through the returned ticket data. have you tried something like the below already and it wasn’t the behavior you desired?:

steps:
   - action:
       action_name: Ticket_Search
       input_args:
           createdTimeGTE: data.createdTimeGTE
           createdTimeLT: data.createdTimeLT
           email: meta_info.userEmail
           requesterId: data.requesterId
           statusId: data.statusId
       output_key: Ticket_Search_output
    - script:
        output_key: ticket_chunks
        input_args:
            ticket_list: data.Ticket_Search_output.result
        code: |
            return [ticket_list[i:i + 100] for i in range(0,len(ticket_list), 100)]
    - for:
        each: chunk
        ...
    - return:
        ...

this may be 6 one way, half a dozen the other, but i thought i’d ask anyways.

By the same data, I mean that there are 5 separate api calls each with their correct paginated data, but those 5 api calls are being repeated many times (along with the initial get status api and the llm call) as the plugin is repeating itself many times.

I haven’t tried a solution like that, but I did want to put some guardrails on this so too many api calls are not made if the llm / user decides to query too much data. I’ll see if I can try a similar recursive expression with a hard limit at another time, but I would still like to understand why this plugin is getting repeatedly executed and what I can do to stop it and just process with the data it has.

​@andrewwhitley It sounds like your plugin is being called multiple times instead of just once and that is definitely something we don’t want.  Your implementation looks great and from the looks of it you are returning A LOT of data based on your search. Are you trying to trigger SDA by any chance? 

Also, can you do me a favor and check what the output of the activity is in the log conversational_process.step.execute should be one the last logs before dm.assistant.message

PS: you don’t need a script expression to create that dummy loop anymore, you can create an array inline in the for expression like this:

in: ["0","0","0",”0”,”0”]

Yes it is returning a lot of data; I am not restricting the contents via data mapping as I wanted to enable people to be able to search on and build reports on just about anything via SDA. SDA is working great with the smaller data sets in this use case.

Thanks for the tip, I will adjust to use the inline array!

For the conversational_process.step.execute log, I tried it again and my queries did end up working today after 2-4 loop iterations so that is a great improvement. I would still like to avoid iteration altogether though if possible.
On the final success, I am getting this:
Large output of size 436354 bytes produced. Actual value omitted

For the times where I don’t believe it succeeded, I have this:
"activity_update":{
"name":"action"
"status":"ACTIVITY_STATUS_PROCESSING"
"output":NULL
}

On previous day’s logs, there is not a conversational_process.step.execute log before a dm.assistant.message because they always timed out before it could send a proper message. The only ones I see that look interesting are the same fail as today:
activity_update":{
"name":"action"
"status":"ACTIVITY_STATUS_PROCESSING"
"output":NULL
}
The rest of conversational_process.step.execute logs are about the action / llm outputs and decision tree.

Thank you Kevin, I had a lot of improvements to make based upon the doc. I updated my plugin description and added in data mapping (to make it easier to process/take up less data) as well as add in display_instructions_for_model. It seems to be working better now

Great to hear! If you see that the behavior is making duplicate plugin calls again. Definitely let us know!