 | basenine 5/28/2009 3:20:43 AM Would this help to enable integration with Google Calendars?
|
 | Rick Cogley 7/25/2010 6:11:23 PM I can see how this would open interesting possibilities.
|
 | Desmond Beatty 1/10/2011 8:19:06 AM We are designing our "lead" application from which all others will be controlled. This is more than an interesting possibility for us, it is a signifiant opportunity for the platform that allows us to to this easily.
|
 | Kirill Bondar 9/11/2012 12:46:03 PM The development is started. To ensure the feature will satisfy your needs, please post here a link to the API documentation you plan to integrate.
|
 | The Angel eXchange Admin 9/18/2012 12:18:49 PM Kirill
The fundamental requirement in this request for Angel eXchange is the ability to trigger events in 3rd party applications from TeamDesk workflows. (We currently poll fields in TeamDesk to see if a given flag is set - not nice).
Calling a URL (into which we can insert TeamDesk Record IDs and other TeamDesk as parameters), allows our integration code to write back to TeamDesk records any result we like asynchronously (ie however long after the event is triggered)
The simplest spec for this capability is "fire and forget" and move to the next step in the Workflow.
An improvement might be to support optional real time replies (eg success / fail/) with timeouts in some way.
Thanks
Desmond
|
| Kirill Bondar 9/19/2012 2:54:44 AM At the moment we are at the stage we are able to send GET requests, parse the response and update the record the action is triggered for. We are handling all failure responses (e.g. non 200-OK codes) ourselves, plus we'll provide optional "error formula" to check for error conditions in a 200-OK response.
POST support is planned for a next stage - technically it is all the same but as POST requires more information from the app and we are in doubt how to organize the interface to keep it simple.
Stay tuned - it is nearly completed.
|
| Kirill Bondar 9/19/2012 7:15:04 AM Okay, first version is online for preview - you can now create Call Url actions and use them in workflow rules and custom buttons. The action performs HTTP GET requests (support for POST and more advanced options is planned for the next stage) and understands responses in plain text, XML and JSON formats. Beside general purpose Name and Description fields the action has: Url: use <% %> code blocks to provide parameters, for example: https://www.teamdesk.net/secure/api/<% AppId() %>/service.asmx Upon request the service can either return failure code [this will be added in a log and further processing will be stopped] or report OK and provide error message in the response. To help dealing with such a situation there is an Error Formula field - you can extract error message from the response or return NULL if response is OK. To deal with the data returned by the server there is a new Response() function that takes three forms: Response() with no arguments return the "raw" content of the server response - you can use it if server provides the result in a plain text format. Response("text") - extracts named data from the response in an XML or JSON format. In case of XML the text should be a valid XPath expression, in case of JSON it's a string in form of "property.property[index].property". The function returns the value as text. Response("text", Type) - performs as previous one but also tries to convert the result to TeamDesk-specific type. You can use calls to Response() in both error formulas and assignments. |
 | Slava Shinderov 9/19/2012 8:32:33 AM |
| Kirill Bondar 9/19/2012 8:46:54 AM Further plans: * Extend support to custom HTTP headers and POST requests; * Make <% %> code blocks context sensitive - e.g. they should take care to transform and encode the data according to a format you make a request in - for XML they should encode < and > in a text, for JSON they should add quotes around the text. By the way, at the moment code blocks in URL field auto-encode the text according to URL rules. * Support for copy-paste mode - many services provide raw dump of the request with placeholders, you can see it for example in our SOAP API [ https://www.teamdesk.net/secure/api/1/service.asmx?op=Create ]. We want you to be able to paste such a description and we'll take care of splitting it into URL, Headers and body. |
| basenine 9/19/2012 8:50:57 AM Looks good.
Just fixed a column error for you - in JSON was referencing to [Company Name]... not [Company]
Works now ;)
|
| basenine 9/19/2012 9:04:40 AM This is awesome..... just awesome
well done guys
|
| The Angel eXchange Admin 9/19/2012 9:53:33 AM Kirill, Slava et al
This is the most powerful innovation to your offering since we signed up nearly two years ago. Good Job! Thanks.
|
 | Tommie Fourie 9/20/2012 2:03:24 AM Kirill & Slava
Just a Thank you from South Africa, you are awesome keep up the good work, Mine is working wonderfull.
Maybe for stage Two how about group selections iso one to one
|
| basenine 9/25/2012 10:57:47 PM I'm guessing we can do Periodic Workflow rules to?
This may help with a Weather application I'm doing...i.e. daily callURL to weather api
|
| Slava Shinderov 9/26/2012 12:48:06 AM @Brett yes, you may use "Call Url" action in any kind of trigger or custom button without limits.
|
 | Rick Cogley 9/27/2012 7:41:07 PM I will describe a problem Slava helped me understand, that might be relevant. I have an exchange rate table for pulling rates into expenses, and I want to keep a history of the rates we used for a given expense, for data integrity. I had everything in one table, and mark the latest active rates with a checkbox. I was trying to create new rates monthly with a periodical trigger, and in turn trigger call-url to grab the rates.
However, you cannot call a workflow from a workflow, so it does not work. The way to fix it is, split the active rate table from a history table. Update the rate using call-url in the active rate table, using a periodic trigger, and in the same trigger write to the history table using a record create action.
|
| basenine 9/27/2012 10:04:19 PM This is Good Rick,
My previous Employer came up with the same solution for when the price changed in our Material Buy Price - it would create a Material History record based on the change so you could graph the increase/decrease(!) when it occurred.
Thanks for sharing the idea - I reckon we should all use the Forum more for sharing these tips. The more we share the quicker and better we grow, which in the long run will make TD more sustainable.
Cheers
|
| Kirill Bondar 7/20/2016 9:57:58 AM |
| Rick Cogley 7/20/2016 4:20:46 PM Wow, that's great!
|
| Kirill Bondar 6/6/2017 10:28:16 AM To simplify debugging we've added logging section for Call URL actions - there you'll be able to see what you were sending and what was server's response.
|
