Skip to main content
Solved

Astea API - Get a list based on criteria

  • September 12, 2022
  • 3 replies
  • 396 views

Forum|alt.badge.img

Hey all,

 

I am trying to make an API call in Astea to retrieve all items that match a certain criteria. I can currently get 1 item to be retrieved sucessfully, but not all items.  Ideally, I would like to get my information from the top level of Installed Items so that I can retrieve other data in a single call.

 

The current call I am making which gets me a single item returned in the results:

<root xmlns:dt="urn:schemas-microsoft-com:datatypes">
    <session email="" alias="">
        <state bc_name="item_installed">
            <action name="getdescrtable">
                <attribute table_name="item_inst" key_name="ce_pref_comm" key_value="E" element_name="ce_email_id" default_value=""/>
            </action>
        </state>
    </session>
</root>

 

Ideally I would like to call something like:

<root xmlns:dt="urn:schemas-microsoft-com:datatypes">
    <session email="" alias="">
        <state bc_name="item_installed">
            <action name="export">
                <attribute bo_name="main" key_name="ce_pref_comm" key_value="E" columns="item_id,serial_no,tagno,ce_pref_comm,ce_email_id,cc_cconth_id"/>
            </action>
        </state>
    </session>
</root>

 

I have had a look at the ‘ExecQueryNoLimit’ action, but I am struggling to figure out the ‘query_name’ I should use.

 

I can make multiple other calls without issue, so this is more around knowing exactly will call to make.  I should also note that we are running a Cloud instance on version 14.0.

 

Any help would be greatly appreciated.

Best answer by Christophe

Hello what we do in that case we look at in Alliance if there is a scroller which display the data needed , we use the debug mode and then we are able to fin the query to use. this need to be handle with caution as you could retreive a lot of data, so for exemple i think the” installed item qbe” is what you are looking for the debug mode will give you the entity_name = ‘item_installed’ and the query_name “item_installed_scrl” you can add the argument in your API

Execquery will retreive the data from the database so the cc_ column will not be part of the retreive

View original
Did this topic help you find an answer to your question?

3 replies

Forum|alt.badge.img+11
  • Sidekick (Partner)
  • 85 replies
  • Answer
  • September 14, 2022

Hello what we do in that case we look at in Alliance if there is a scroller which display the data needed , we use the debug mode and then we are able to fin the query to use. this need to be handle with caution as you could retreive a lot of data, so for exemple i think the” installed item qbe” is what you are looking for the debug mode will give you the entity_name = ‘item_installed’ and the query_name “item_installed_scrl” you can add the argument in your API

Execquery will retreive the data from the database so the cc_ column will not be part of the retreive


Forum|alt.badge.img
  • Author
  • Do Gooder (Customer)
  • 2 replies
  • September 15, 2022

Christophe,

 

Thanks a bunch for the information.  Finding the ‘query_name’ for me has resolved 90% of the issue I was having. The rest can be resolved by sending a secondary query against a filtered list.

 

In regards to the debug mode, are you talking about “IsDebugMode”, “IsDebugModeFW” and “IsDebugModeIDO” from the Global.xml?

 

Greatly appreciate the info.


Phil Seifert
Ultimate Hero (Employee)
Forum|alt.badge.img+24
  • Ultimate Hero (Employee)
  • 1368 replies
  • September 17, 2022

Hi Andrew,

In regards to your  question about debug mode Christophe mentions, he is referring to isDebugMode for the profile you are using in the global.xml.

 This can be enabled/disabled without requiring IISRESET via Configuration Editor. Once enabled, the application writes Info events to the profile event log which contain the queries sent to the database.

it is not recommended to leave this enabled long on a production system due to performance. If you do this, only enable for while you require to capture all events. Better still would be to do this on an UAT system instead of Production as usually there will be fewer concurrent actions going on than normally the case in Production  

I suggest clearing the event log just before taking the action so you do not have to review as many events 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings