dctrack Web Services API - Ticketing User Guide 3.0.0

Transcription

2 This document contains proprietary information that is protected by copyright. All rights reserved. No part of this document may be photocopied, reproduced, or translated into another language without express prior written consent of Raritan, Inc. Copyright 2013 Raritan, Inc. All third-party software and hardware mentioned in this document are registered trademarks or trademarks of and are the property of their respective holders. FCC Information This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference in a commercial installation. This equipment generates, uses, and can radiate radio frequency energy and if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. Operation of this equipment in a residential environment may cause harmful interference. VCCI Information (Japan) Raritan is not responsible for damage to this product resulting from accident, disaster, misuse, abuse, non-raritan modification of the product, or other events outside of Raritan's reasonable control or not arising under normal operating conditions. If a power cable is included with this product, it must be used exclusively for this product.

3 Contents Chapter 1 Introduction 1 Overview... 1 Chapter 2 Using Web API to Retrieve External 2 Overview... 2 Default Web API Username and Password... 2 Technical Description Summary... 3 Supported Technologies... 3 API Operations... 4 Supported Fields in the Ticketing API... 5 API Request/Response Examples TicketCreate Example TicketUpdate Example TicketDelete Example TicketGetStatus Example Appendix A References 25 Appendix B Ticketing WS-API Process Flow 26 Index 29 iii

4 Chapter 1 Introduction In This Chapter Overview... 1 Overview This document describes the dctrack web services API. The dctrack Web Services Ticketing API allows an external ticketing system to create and update a dctrack ticket. 1

5 Chapter 2 Using Web API to Retrieve External In This Chapter Overview... 2 Default Web API Username and Password... 2 Technical Description Summary... 3 Supported Technologies... 3 API Operations... 4 API Request/Response Examples Overview The following is an example use case of this API. A ticket system facilitates the creation or change of a dctrack ticket. The ticket system electronically transfers information about the ticket to dctrack such as ticket number, action (add or Decommission to Archive), description and optionally - name, make, model, serial number, etc. dctrack provides an incoming external ticket list screen to allow a user to approve, reject, change or add information to the ticket and use that ticket to generate a dctrack Request or delete a ticket all together. This reduces the time and improves the accuracy of creating requests and work orders in dctrack. A ticket system can periodically or on-demand request status of a dctrack ticket. This ensures ticket status accuracy with no manual effort. Default Web API Username and Password Use this default username and password to perform integration through a web API interface. Username web_api Password raritan 2

6 For all ticketing API calls, the username and password is passed through a WS-Security SOAP envelope. For getting the WSDL itself, there is no authentication required. However, for actually perform actions such as CreateTicket, DeleteTicket and so on, the WSSecurity SOAP envelope with the username and password must be embedded within it. Use the following URL: IP/Hostname>/TicketingService/TicketingService?wsdl Note: For dctrack and above, the link is automatically redirected to IP/Hostname>/axis2/services/TicketingService?wsdl Technical Description Summary This is a web services API that uses SOAP over HTTPS only (port 443). Creating, updating, deleting and requesting the status of can be done through this interface (initiated by the client application s API connector). The API connector is the software that is added to the client application and implements this API. The API uses Web Services Definition Language (WSDL) files to define the objects in the web services API. The WSDL will define data types, field names, and so on. Authentication is done using WS-Security. The client application must use an existing dctrack user s credentials in the web services API call in order to be authenticated. LDAP credentials are also allowed. At this time all Access Levels including Viewer will be permitted to use the API and create, update and delete. This allows the dctrack Gatekeeper to configure a user with a permission level that gives a user view only access to all aspects of the dctrack user interface, but still allow them to interact with dctrack via the Ticketing API. Supported Technologies Development Language: Java Web Service Framework: Axis2 and CXF 3

7 API Operations The dctrack ticketing web services API contains several operations as follows: Operation TicketCreate TicketUpdate TicketDelete Description This operation is used to create a ticket in dctrack. This call includes an action. Current supported actions are Add Item and Decommission to Archive Item. Move Item and other actions are not supported using this API. The TicketCreate operation creates one ticket at a time, and the ticket must be for one item and one action. For example, install a server. A dctrack user reviewing the information submitted with the ticket creation or update request to identify missing or unclear information and mark it as such. When the client application queries dctrack for the ticket status and receives a response indicating that the ticket requires additional information, the client application can use TicketUpdate to re-send all the information with the necessary updates or additions to dctrack. Updates will only be accepted for a previously created ticket. For a data ports, if the ticket update contained a new port name, it will add that port to the ticket. However, if the ticket update was missing a port that was sent in the original ticket, it will not be deleted from the ticket. If the intention is to delete ports, then the entire ticket should be deleted using TicketDelete and recreated using the TicketCreate. If a ticket is deleted, the original ticket number could be used. This operation is used to request the deletion of a previously sent ticket if the user of the client application wishes to abandon the original ticket. Please note that dctrack may or may not allow the ticket to be deleted depending on that ticket s status, and so long as the delete request has not been approved. 4

8 Operation Description TicketGetStatus This operation is used by the client application to request the status of one or more tickets that were previously created in dctrack by the TicketCreate operation. dctrack will respond with the current status. It is important to note that when a ticket is completed within dctrack,dctrack will not initiate a call to the client application to report back. The client application is responsible to regularly poll dctrack for the status. Supported Fields in the Ticketing API A client application can send dctrack its ticket information which is used to produce a corresponding ticket in dctrack. The following shows all the fields that can be sent in an API call. The table column headings are as follows: Field: The name of the field containing data Ticket Actions Applicability: The inclusion of the field for a particular action. Access Type: Whether the data is received from the client application (write) and/or the data is sent back by dctrack (read) Required: Indicates whether this field must be included in the API call, or it is optional data. Data Model: The area that this field applies to in the dctrack data model. TicketCreate/TicketUpdate API Operations Note: One Ticket may contain one Item element, one Power Ports element and many Data Ports elements. Field Ticket Actions Applicability Ticket Number All actions Read/Write (cannot be changed after initial creation) Access Type Required Data Model Yes Description All actions Read/Write Yes Ticket Action All actions Read/Write (cannot be changed after initial creation) Yes 5

9 Field Ticket Actions Applicability Access Type Required Data Model Due Date All actions Read/Write No Creation Date All actions Read-only N/A (provided by dctrack) Update Date All actions Read-only N/A (provided by dctrack) Completed Date All actions Read-only N/A (provided by dctrack) Last Modified Date All actions Read-only N/A (provided by dctrack) Username All actions Read/Write Yes (authenticating user) Processed By All actions Read-only N/A (provided by dctrack) System Vendor All actions Read/Write No System Id All actions Read/Write No Status All actions Read-only N/A (provided by dctrack) Missing Fields All actions Read-only N/A (provided by dctrack) Status Comments All actions Read-only N/A (provided by dctrack) Location All actions Write-only No Items Item Name All actions Write-only No Items Class All actions Write-only No Items Subclass Add Item Write-only No Items Make Add Item Write-only No Items Model Add Item Write-only No Items Cabinet U Position Add Item, Move Item Add Item, Move Item Write-only No Items Write-only No Items Destination Cabinet Move Item Write-only No (Not supported in this release) Items Destination U Move Item Write-only No (Not supported in this Items 6

10 Field Position Ticket Actions Applicability Access Type Required Data Model release) Type Add Item Write-only No Items Function Add Item Write-only No Items Serial Number Add Item Write-only No Items Asset Tag Add Item Write-only No Items Port Name Add Item Write-only No Data Ports Connector Add Item Write-only No Data Ports Media Add Item Write-only No Data Ports Protocol Add Item Write-only No Data Ports Speed Add Item Write-only No Data Ports Color Add Item Write-only No Data Ports VLAN Add Item Write-only No Data Ports MAC Address Add Item Write-only No Data Ports IP Address Add Item Write-only No (Not supported in this release) Data Ports Port Name Prefix Add Item Write-only No Power Ports Quantity Add Item Write-only No Power Ports Connector Add Item Write-only No Power Ports Phase Add Item Write-only No Power Ports Volts Add Item Write-only No Power Ports Nameplate Watts Add Item Write-only No Power Ports Budget Watts Add Item Write-only No Power Ports Redundancy Add Item Write-only No Power Ports Power Factor Add Item Write-only No Power Ports Color Code Add Item Write-only No Power Ports 7

11 TicketDelete API Operation Field Ticket Actions Applicability Ticket Number All actions Read/Write (cannot be changed after initial creation) Access Type Required Data Model Yes TicketGetStatus API Operation Field Ticket Actions Applicability Ticket Number All actions Read/Write (cannot be changed after initial creation) Access Type Required Data Model Yes Creation Date All actions Read-only N/A (provided by dctrack) Update Date All actions Read-only N/A (provided by dctrack) Completed Date All actions Read-only N/A (provided by dctrack) Last Modified Date All actions Read-only N/A (provided by dctrack) Processed By All actions Read-only N/A (provided by dctrack) Status All actions Read-only N/A (provided by dctrack) Missing Fields All actions Read-only N/A (provided by dctrack) Status Comments All actions Read-only N/A (provided by dctrack) Field Descriptions The following table explains the fields used in API calls. Field Ticket Number Field description A unique number for the ticket generated by the client application 8

12 Field Description Ticket Action Due Date Creation Date Update Date Completed Date Field description Description of the ticket entered by the user of the client application. If information is not sent in the optional fields for Item and Ports, this field should contain enough information about what is required such that the dctrack user addressing this ticket can successfully process it. Must be one of the supported ticket actions The date for when the work referenced in the ticket is expected to be completed The date/time dctrack received the ticket from the client application The date/time dctrack received an update for the ticket by the client application The date/time the ticket was completed Last Modified Date The date/time the ticket was modified by a dctrack user from within dctrack Username Processed By System Vendor System Id Status Missing Fields Status Comments The username that came in with the ticket and was used for authentication The username of the user that processed the ticket in dctrack A name that references the client application that sent the ticket to dctrack An id that references the client application that sent the ticket to dctrack The status of the ticket. See a list of statuses below and flow chart in Appendix B An XML-formatted description of the fields that contain missing/unknown or incomplete information. The client application can parse this information to identify which fields in the ticket require to be updated and resent in a TicketUpdate call A comment string that the dctrack user must include with the ticket if at least on ticket field was rejected. Location Item Name Class Subclass Make Model The name of the data center location (Site) in the dctrack database where this item referenced in this ticket resides The name of the item referenced in this ticket. For an Add Item, the name must be unique within the location. For a Decommission to Archive Item and Move Item tickets, the item name must already exist in dctrack. The dctrack class to which the item belongs. Only Device class is supported in this release. The dctrack subclass to which the item belongs (if applicable for the class). For Device class, only standard and blade chassis subclasses are supported in this release. The manufacturer of the model used for this item The model of the hardware used for this item 9

13 Field Cabinet U Position Field description The cabinet in which the added item will reside The cabinet U position at which the added item will reside. This references the bottom most U position of the item based on a cabinet numbered with U position 1 at the bottom. Destination Cabinet The cabinet where the item is to be moved Destination U Position Type Function Serial Number Asset Tag The U position where the item is to be moved A type for the item. A function for the item The serial number of the item The asset tag of the item Port Name Connector Media Protocol Speed Color VLAN MAC Address IP Address The data port name. (note that multiple ports can be created by repeating the port information for each port required) The connector type for the data port The media of the port (Twisted-pair, multimode, singlemode or coax) The protocol for the data port The data rate at which the data port operates The color code assigned to this data port The VLAN or grouping assigned to this data port The MAC address for this data port The IP address for this data port Port Name Prefix Quantity Connector Phase Volts Nameplate Watts Budget Watts The power port name prefix. A two digit sequential number starting at 01 will be appended to this prefix to create the port name. The quantity of power ports (power supplies) to be created The connector type for the power port The phase (Single phase (2-wire), single phase (3-wire), three phase Delta, three phase wye) Operating voltage range of the power supply The manufacturer s specification for the power supply wattage The estimated budget value of the power the power supply will consume. Typical range is 50 to 80% of Nameplate. Redundancy Power supply redundancy (N, N+1, N+2,... N+x) where x = Quantity 1 10

14 Field Field description Power Factor The power factor of the power supply, Valid range is > 0 and <= 1. Default = 1 Color Code The color code assigned to this power port. Ticket Statuses The following are the possible statuses that a ticket can be in: Received Incomplete Updated dctrack Request Issued dctrack Request Approved dctrack Request Rejected dctrack Request Updated dctrack Work Order Issued dctrack Work Order Completed dctrack Request Complete Archived dctrack will accept a delete or an update from the external system only when the ticket is in the following status: Received, Incomplete and Updated. Refer to Ticketing WS-API Process Flow (on page 26) for a flow chart describing the above listed statuses. Error Codes The following table shows a list of the possible error codes that may be encountered. Error String Code Description TICKET_CREATE_FAILED 1801 Failed to create ticket due to internal error TICKET_UPDATE_FAILED 1802 Updating the ticket failed due to internal error. TICKET_NUMBER_EXISTS 1803 Ticket Number exists TICKET_DEL_FAILED 1804 Failed to delete tickets due to internal error. TICKET_NUMBER_MISSING 1805 Ticket Number missing in 11

15 Error String Code Description request TICKET_DESCRIPTION_MISSING 1806 Ticket Description missing in request TICKET_DOES_NOT_EXIST 1807 This ticket does not exist MORE_THAN_ONE_TICKET_FOUND 1808 More than one ticket with same ticket number found! TICKET_FETCH_FAILED 1809 Failed to retrieve a list of tickets TICKET_DATA_PORT_NAME_NOT_UNIQUE 1810 The data port already exists for this ticket. Cannot add the data port with same name TICKET_CANNOT_UPDATE_DELETE 1811 Ticket cannot be updated or deleted since it is in <state> TICKET_GET_STATUS_FAIL 1812 Getting the ticket status failed due to internal error TICKET_ACTION_MISSING 1813 Ticket action is missing in request TICKET_DATA_PORT_DOES_NOT_EXIST 1814 Ticket data port does not exist TICKET_POWER_PORT_DOES_NOT_EXIST 1815 Ticket power port does not exist TICKET_XSD_VALIDATION_FAILED 1816 XSD Validation Error,s TICKET_STATUS_CODE_INVALID 1817 Internal Error: Ticket Status Code is invalid. Cannot update or delete ticket. Contact Raritan Technical support. TICKET_DATA_PORT_NAME_EMPTY 1818 dctrack cannot accept blank data port name TICKET_POWER_PORT_PREFIX_EMPTY 1819 dctrack cannot accept blank power port prefix 12

16 API Request/Response Examples TicketCreate Example The following is an example of an API Request to create a ticket in dctrack to add a new device called NJSQL1 with two data ports and 2 power supplies: <?xml version='1.0' encoding='utf-8'?> <S:Envelope xmlns:s=" <S:Header> <ns2:security xmlns:ns2=" xt"> <usernametoken> <username>admin</username> <password>raritan</password> </usernametoken> </ns2:security> </S:Header> <S:Body> <TicketCreateRequest xmlns=" xmlns:ns2=" <ticket> <ticketnumber>tkt0001</ticketnumber> <description>please add device with name NJSQL1</description> <action>add Item</action> <systemvendor>1001</systemvendor> <systemid>re345</systemid> <location>site1001</location> <itemname>njsql1</itemname> <itemclass>device</itemclass> <itemsubclass>server</itemsubclass> 13

17 <make>hp</make> <model>proliant DL320 G5p1</model> <cabinetname>1a</cabinetname> <uposition>1</uposition> <serialnumber> </serialnumber> <assetnumber>1234</assetnumber> <type>server</type> <function>development</function> <dataports> <portname>net01</portname> <connector>rj45</connector> <media>100baset</media> <protocol>tcp/ip</protocol> <speed>100mb</speed> <color>red</color> <macaddress>00:01:03:c2:1a:a1</macaddress> <vlan>vlan_1</vlan> </dataports> <dataports> <portname>net02</portname> <connector>rj45</connector> <media>100baset</media> <protocol>tcp/ip</protocol> <speed>100mb</speed> <color>red</color> <macaddress>00:01:03:c2:1a:a1</macaddress> <vlan>vlan_1</vlan> </dataports> <powerport> <portnameprefix>ps</portnameprefix> 14

18 <quantity>2</quantity> <powerfactor>0.9</powerfactor> <connector>iec-c14</connector> <voltage>120~240</voltage> <phase>single Phase</phase> <nameplatewatts>500</nameplatewatts> <budgetwatts>300</budgetwatts> <redundancy>n+1</redundancy> </powerport> </ticket> </TicketCreateRequest> </S:Body> </S:Envelope> The API response would be: <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" pe/"> <soapenv:body> <TicketCreateResponse xmlns=" <response> <statuscode xmlns=" tatuscode> <resmessage xmlns=" essful operation</resmessage> </response> <ticketid>302</ticketid> <ticketnumber> TKT0001</ticketNumber> </TicketCreateResponse> </soapenv:body> 15

19 </soapenv:envelope> 16

20 TicketUpdate Example The following is an example of an API Request to update U Position in a ticket in that was previously sent to dctrack. Note that an update contains all the previously sent fields even if they contained no change. Note that this call does not contain the <ticketaction> element: <?xml version='1.0' encoding='utf-8'?> <S:Envelope xmlns:s=" <S:Header> <ns2:security xmlns:ns2=" xt"> <usernametoken> <password>raritan</password> <username>admin</username> </usernametoken> </ns2:security> </S:Header> <S:Body> <TicketUpdateRequest xmlns=" xmlns:ns2=" <ticket> <ticketnumber>tkt0001</ticketnumber> <description>please add device with name NJSQL1</description> <systemvendor>1001</systemvendor> <systemid>re345</systemid> <location>site1001</location> <itemname>njsql1</itemname> <itemclass>device</itemclass> <itemsubclass>server</itemsubclass> <make>hp</make> 17

21 <model>proliant DL320 G5p1</model> <cabinetname>1a</cabinetname> <uposition>20</uposition> <serialnumber> </serialnumber> <assetnumber>1234</assetnumber> <type>server</type> <function>development</function> <dataports> <portname>net01</portname> <connector>rj45</connector> <media>100baset</media> <protocol>tcp/ip</protocol> <speed>100mb</speed> <color>red</color> <macaddress>00:01:03:c2:1a:a1</macaddress> <vlan>vlan_1</vlan> </dataports> <dataports> <portname>net02</portname> <connector>rj45</connector> <media>100baset</media> <protocol>tcp/ip</protocol> <speed>100mb</speed> <color>red</color> <macaddress>00:01:03:c2:1a:a1</macaddress> <vlan>vlan_1</vlan> </dataports> <powerport> <portnameprefix>ps</portnameprefix> <quantity>2</quantity> 18

22 <powerfactor>0.9</powerfactor> <connector>iec-c14</connector> <voltage>120~240</voltage> <phase>single Phase</phase> <nameplatewatts>500</nameplatewatts> <budgetwatts>300</budgetwatts> <redundancy>n+1</redundancy> </powerport> </ticket> </TicketCreateRequest> </S:Body> </S:Envelope> The API response would be: <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" pe/"> <soapenv:body> <TicketUpdateResponse xmlns=" <response> <statuscode xmlns=" tatuscode> <resmessage xmlns=" essful operation</resmessage> </response> <ticketid>302</ticketid> <ticketnumber>tkt0001</ticketnumber> </TicketUpdateResponse> </soapenv:body> </soapenv:envelope> 19

23 TicketDelete Example The following API Request is to delete a previously sent ticket: <?xml version='1.0' encoding='utf-8'?> <S:Envelope xmlns:s=" <S:Header> <ns2:security xmlns:ns2=" xt"> <usernametoken> <username>admin</username> <password>raritan</password> </usernametoken> </ns2:security> </S:Header> <S:Body> <TicketDeleteRequest xmlns=" xmlns:ns2=" <ticketnumber>tkt0001</ticketnumber> </TicketDeleteRequest> </S:Body> </S:Envelope> The API Response for a successful delete is as follows: <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" pe/"> <soapenv:body> <TicketDeleteResponse xmlns=" 20

24 <response> <statuscode xmlns=" tatuscode> <resmessage xmlns=" essful operation</resmessage> </response> <ticketnumber>tkt0001</ticketnumber> </TicketDeleteResponse> </soapenv:body> </soapenv:envelope> 21

25 TicketGetStatus Example The following is an example of an API Request to retrieve the status of several tickets: <?xml version='1.0' encoding='utf-8'?> <S:Envelope xmlns:s=" <S:Header> <ns2:security xmlns:ns2=" xt"> <usernametoken> <username>admin</username> <password>raritan</password> </usernametoken> </ns2:security> </S:Header> <S:Body> <TicketGetStatusRequest xmlns=" xmlns:ns2=" <ticketnumber>tkt0001</ticketnumber> <ticketnumber>tkt0002</ticketnumber> </TicketGetStatusRequest> </S:Body> </S:Envelope> The following would be the response with the status of both tickets. <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" pe/"> <soapenv:body> 22

26 <TicketGetStatusResponse xmlns=" <response> <statuscode xmlns=" tatuscode> <resmessage xmlns=" essful operation</resmessage> </response> <ticketstatus> <ticketnumber>tkt0001</ticketnumber> <status>updated</status> <statuscomments xmlns:xsi=" xsi:nil="true" /> <missingfields /> <creationdate> t12:30: :00</creation Date> <processedby xmlns:xsi=" xsi:nil="true" /> </ticketstatus> <ticketstatus> <ticketnumber>tkt0002</ticketnumber> <status>dctrack Request Issued</status> <statuscomments xmlns:xsi=" xsi:nil="true" /> <missingfields /> <creationdate> t13:30: :00</creation Date> <processedby>joesmith</processedby> </ticketstatus> 23

27 </TicketGetStatusResponse> </soapenv:body> </soapenv:envelope> The following would be a response for the same API Request example when TKT0001 exists but TKT0002 does not. Note that in this case, when at least one ticket causes an error, the Response contains the error about those tickets and no status is provided for the tickets that don t have an issue. In this case the client application must resend the TicketGetStatus Request with the correct ticket numbers. <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" pe/"> <soapenv:body> <TicketGetStatusResponse xmlns=" <response> <statuscode xmlns=" </statuscode> <resmessage xmlns=" ticket does not exist: TKT0002</resMessage> </response> </TicketGetStatusResponse> </soapenv:body> </soapenv:envelope> 24

28 Appendix A References In This Chapter Web Services Security (WS-Security) Version Apr Updated 01 Mar cure/ Web Services Security UsernameToken Profile 1.0 OASIS Standard , March ame-token-profile-1.0.pdf (see 25

29 Appendix B Ticketing WS-API Process Flow 26

30 Appendix B: Ticketing WS-API Process Flow 27

31 Index A API Operations 4 API Request/Response Examples 13 D Default Web API Username and Password 2 E Error Codes 11 F Field Descriptions 8 I Introduction 1 O Overview 1, 2 R References 25 S Supported Fields in the Ticketing API 5 Supported Technologies 3 T Technical Description Summary 3 Ticket Statuses 11 TicketCreate Example 13 TicketCreate/TicketUpdate API Operations 5 TicketDelete API Operation 8 TicketDelete Example 20 TicketGetStatus API Operation 8 TicketGetStatus Example 22 Ticketing WS-API Process Flow 11, 26 TicketUpdate Example 17 U Using Web API to Retrieve External 2 29

32 U.S./Canada/Latin America Monday - Friday 8 a.m. - 6 p.m. ET Phone: or For CommandCenter NOC: Press 6, then Press 1 For CommandCenter Secure Gateway: Press 6, then Press 2 Fax: for CommandCenter NOC: tech-ccnoc@raritan.com for all other products: tech@raritan.com China Beijing Monday - Friday 9 a.m. - 6 p.m. local time Phone: Shanghai Monday - Friday 9 a.m. - 6 p.m. local time Phone: GuangZhou Monday - Friday 9 a.m. - 6 p.m. local time Phone: India Monday - Friday 9 a.m. - 6 p.m. local time Phone: Japan Monday - Friday 9:30 a.m. - 5:30 p.m. local time Phone: support.japan@raritan.com Europe Europe Monday - Friday 8:30 a.m. - 5 p.m. GMT+1 CET Phone: tech.europe@raritan.com United Kingdom Monday - Friday 8:30 a.m. to 5 p.m. GMT Phone +44(0) France Monday - Friday 8:30 a.m. - 5 p.m. GMT+1 CET Phone: Germany Monday - Friday 8:30 a.m. - 5:30 p.m. GMT+1 CET Phone: rg-support@raritan.com Melbourne, Australia Monday - Friday 9:00 a.m. - 6 p.m. local time Phone: Taiwan Monday - Friday 9 a.m. - 6 p.m. GMT -5 Standard -4 Daylight Phone: support.apac@raritan.com