0 Replies Latest reply on Jun 14, 2013 11:46 AM by wby47

    API call taking a long time to create a ticket.

    wby47

      I'm using Perl's LWP to create tickets in WHD. Most of the time, the call takes > 2.5 minutes to receive a response, even though the request is received right away.

       

      The json I'm passing in is something like:

                    { "room": "",

                      "emailClient": true,

                      "emailTech": true,

                      "emailTechGroupLevel": false,

                      "emailGroupManager": false,

                      "emailCc": false,

                      "ccAddressesForTech": "",

                      "emailBcc": false,

                      "bccAddresses": "",

                      "subject": "peas",

                      "detail": "I like peas.",

                      "assignToCreatingTech": false,

                      "problemtype": { "type": "ProblemType", "id": XXX },

                      "isPrivate": false,

                      "sendEmail": false,

                      "location": { "type": "Location", "id": 1 },

                      "clientReporter": { "type": "Client", "id": XXX },

                      "statustype": { "type": "StatusType", "id": 1 },

                      "prioritytype": { "type": "PriorityType", "id": 3 } }


      my $req = HTTP::Request->new('POST', $uri);

      $req->header('Content-Type' => 'application/json');

      $req->content($json);

      my $lwp = LWP::UserAgent->new;

      my $response = $lwp->request($req);

       

      Eventually, this succeeds, and returns a valid ticket.

      $ time ./test_whd_api.pl

                   '_protocol' => 'HTTP/1.1',
                   '_content' => '{"id":255675,"type":"Ticket","lastUpdated":"2013-06-14T16:38:32Z","locationId":1,"statusTypeId":1,"subject":"XXXXX"}

      ',

                   '_rc' => '201',

      [snip]

      real    5m52.988s

      user    0m0.086s

      sys    0m0.034s

      Is it normal for it to take this long to receive a response? Do most people just make an asynchronous request? In this case, I'd really prefer to know for sure that the call succeeded.

       

      In the webhelpdesk log:

      INFO  [2013-06-13 17:25:31]<http-bio-443-exec-109> JobTicketController: Performing action named: create (Request = /helpdesk/WebObjects/Helpdesk.woa/ra/Tickets/?apiKey=xxxxxxxx)

      ERROR [2013-06-13 17:25:31]<http-bio-443-exec-109> ERROR: Unable to get preference for job ticket: null

      [followed by a java backtrace]

      and then:

      WARN  [2013-06-13 17:25:33]<http-bio-443-exec-109> "JobTicket"@1569799888 expression took

      2090 ms: SELECT t0.ASSET_ID, t0.ASSIGNED_TECH_ID, t0.BCC_ADDRESSES, t0.BILLING_RATE_ID,

      t0.BILLING_TERM_ID, t0.CC_ADDRESS_FOR_CLIENT, t0.MAIL_CC_ADDRESS, t0.CLIENT_CREATOR_ID,

      t0.CLIENT_ID, t0.CLOSE_DATE, t0.CUSTOM_1, t0.CUSTOM_2, t0.CUSTOM_3, t0.CUSTOM_4,

      t0.DELETED, t0.DEPARTMENT_ID, t0.DISABLE_EMAIL_TO_ALL_CLIENTS, t0.DISABLE_EMAIL_TO_CLIENT,

      t0.DISABLE_EMAIL_TO_CLIENT_AND_CC, t0.DISCOUNT, t0.DUE_DATE_OVERRIDE, t0.DUE_HOURS_MANUAL,

      t0.ESCALATION_LEVEL, t0.FIRST_RESPONSE_DATE, t0.HAS_BEEN_REASSIGNED,

      t0.INITIALIZED_CUSTOM_FIELDS, t0.IP_ADDRESS, t0.IS_ELIGIBLE_FOR_SURVEY, t0.IS_HOT,

      t0.IS_PRIVATE, t0.IS_TAX_FREE, t0.JOB_COST, t0.JOB_TICKET_ID, t0.JOB_TIME,

      t0.LABOR_TAX_RATE, t0.LAST_CLIENT_REMINDER_DATE, t0.LAST_CLIENT_UPDATE,

      t0.LAST_EMAIL_SEND_DATE, t0.LAST_REMINDER_DATE, t0.LAST_STATUS_UPDATE_TIME,

      t0.LAST_UPDATED, t0.LOCATION_ID, t0.LOGGED_BY_ID, t0.MERGED_PARENT_TICKET_ID, t0.MODEL_ID,

      t0.ORIGINAL_TECH_ID, t0.PARENT_ID, t0.PHONE, t0.PO_NUMBER, t0.PRIORITY_TYPE_ID,

      t0.PROBLEM_TYPE_ID, t0.QUESTION_TEXT, t0.REPORT_DATE, t0.ROOM, t0.SEND_BCC_EMAIL,

      t0.SEND_CARBON_COPY, t0.SEND_CLIENT_EMAIL, t0.SEND_GROUP_MGR_EMAIL,

      t0.SEND_LEVEL_TECH_EMAIL, t0.SEND_TECH_EMAIL, t0.SEND_TO_CLIENT_CC_LIST,

      t0.SERVICE_TIME_ENABLED, t0.SHIPPING, t0.SHOW_DUE_DATE_ON_CALENDAR,

      t0.STATUS_RED_NOTIFICATION_DT, t0.STATUS_TYPE_ID, t0.STATUS_YELLOW_NOTIFICATION_DT,

      t0.SUBJECT, t0.SUBSCRIBER_ID, t0.SURVEY_RESPONSE_ID, t0.TASK_ELEMENT_COMPLETE,

      t0.TASK_ELEMENT_ID, t0.TASK_RUN_ID, t0.TECH_GROUP_LEVEL_ID,

      t0.TICKET_TIME_AS_OF_LAST_UPDATE, t0.TRAVEL_COST, t0.TRAVEL_RATE_ID, t0.TRAVEL_TIME,

      t0.UPDATED_BY_TECH_FLAG, t0.UPDATED_FLAG, t0.USE_DUE_DATE_OVERRIDE_INTEGER,

      t0.WORK_END_DATE, t0.WORK_START_DATE FROM whd.JOB_TICKET t0 WHERE t0.STATUS_TYPE_ID =

      ? withBindings: 1:1[statusTypeId]

      ERROR [2013-06-13 17:25:36]<http-bio-443-exec-109> ERROR: Unable to get preference for job

      ticket: null


      Seems like a MySQL select is the root of the problem (notice how long that query takes) - looks like this will essentially select all tickets of the same status type?

      Here's an 'explain' on that select (with status_type_id set to 1):

      +----+-------------+-------+------+----------------+----------------+---------+-------+-------+-------------+

      | id | select_type | table | type | possible_keys  | key            | key_len | ref   | rows  | Extra       |

      +----+-------------+-------+------+----------------+----------------+---------+-------+-------+-------------+

      |  1 | SIMPLE      | t0    | ref  | STATUS_TYPE_ID | STATUS_TYPE_ID | 5       | const | 93859 | Using where |

      +----+-------------+-------+------+----------------+----------------+---------+-------+-------+-------------+


      If I use curl and don't follow the redirects, I get a 3XX right away; if I do follow the redirects, I get a 5XX error. However, the tickets submitted via the above method *do* get submitted; they just take 3 minutes to get an HTTP response.