scroll

HRBC Connect API Development Overview

Required Development Skills

The guidelines for the skills required for app development are as follows:

  • App development skills using HTTP and HTTPS
  • App development skills using XML
  • More than 2-3 years of experience in Web Service development (Requirements differ depending on what kind of apps are developed.)
  • App development skills using JAVA, C#, PHP and other programming languages
  • Ability to understand the content of HRBC Connect API Guide (this site)
  • Ability to understand how to use HRBC and the data structure of it

 

Specifications Overview

■RESTful API

The interface of the API is designed based on REST.

Users can use GET and POST of an HTTP request to access each resource for performing read or write operations.

XML is used for the data format of communications.

 

■Execution environment

Any language can be selected as long as it is able to control HTTP requests because access is via HTTP REST.

JAVA and PHP have been mostly selected, but .NET Framework is also available.

The user needs to apply in advance for using the Web server where the app is to be executed and register the app with PORTERS.

The authentication from a server other than the pre-registered Web server will be rejected.

 

■Authentication and Authorization

Authentication and authorization are configured in OAuth2.0 based architecture. There are two types of authentication methods.

  • Code authentication
    An app is started by the user who has been logged in to HRBC.
  • Code Direct authentication
    An app is started by the app user.
    This method is used for batch processing that does not involve user operations.

 

■Data structure of HRBC

For actually developing apps or defining requirements, users need to understand the data structure of HRBC.

HRBC stores data in a layered structure.

Check Data structure of HRBC  by referring to the description in the Help for HRBC users.

 

■Non-supported API

This API cannot be used to delete data or attachments. Also, currently, no API for deletion will be developed or open.

 

Usage Examples

Data can be acquired, registered, and updated for the resources for which access privileges are acquired.

The following shows some accessible information, and the examples shown below can be performed.

  • Partition information (Partition)
  • User information (User)
  • Field information (Field)
  • Option information (Option)
  • Companies (Client)
  • Company recruiter (Recruiter)
  • JOB (Job)
  • Personal contact information (Candidate)
  • Resume (Resume)
  • Selection process (Process)
  • Attachment (Attachment)

 

Example 1: Import JOB to the app server

The Job API can be called from the app server to extract the relevant JOB data.

kaihatsugaiyou_1.png

 

Example 2: Register the candidate with HRBC

The Candidate API can be called from the app server to register the candidate with HRBC.

kaihatsugaiyou_2.png

 

Example 3: Acquire the selection situation

The Process API can be called from the app server to extract the relevant selection processes.

kaihatsugaiyou_3.png

 

Request Examples

Example 1: Acquire all JOB fields information

■Request

Method:GET

.../v1/field?partition=1&resource=3&active=-1

The “field” at the end of the URL indicates that Field data are accessed.

The parameter, partition=1, indicates that Partition Id accesses the Field in area 1.

Resource=3 specifies the resource to be accessed, and 3 represents JOB.

Active=-1 indicates that all the fields--both used and unused fields--are acquired.

 

■Response

A list including the attribute information of the field can be acquired in XML.

Response Body

<Field Count="2" Start="0" Total="1234">
 <Item>
  <Field.P_Id>100</Field.P_Id>
  <Field.P_Name>Position</Field.P_Name>
  <Field.P_Type>1</Field.P_Type>
 </Item>
 ...
</Field>

 

Example 2: Acquire job opening information updated between March 25 and 31, 2015 Japan time.

■Request

Method:GET

.../v1/job?partition=1&field=Job.P_Id,Job.P_Position,Job.P_UpdateDate&condition=Job.P_UpdateDate:ge:2015/03/24%2015:00,Job.P_UpdateDate:lt:2015/03/31%2015:00

The “job” at the end of the URL indicates that the JOB data are accessed.

The next parameter “partition=1” indicates that Partition Id accesses the JOB in area 1.

The “condition=” specifies the date the JOB was updated (Job.P_UpdateDate) as the extraction condition.

The “ge” that is specified for the first condition stands for Greater Than or Equal, representing >=.

The “lt” that is specified for the second condition stands for Less Than, representing <.

The conditional expressions of these two conditions are as follows:

  Job.P_UpdateDate >= 2015/03/24 15:00 AND Job.P_UpdateDate < 2015/03/31 15:00

Note that the reason why “15:00” is specified for the time is because the date and time must all be specified in UTC in the HRBC API, and thus the time difference between the local area and Japan is taken into consideration.

 

■Response

The XML shown below can be acquired.

Response Body

<Job Start="0" Count="10" Total="2234">
 <Item>
  <Job.P_Id>10001</Job.P_Id>
  <Job.P_Position>Software Development Engineer</Job.P_Position>
  <Job.P_UpdateDate>2015/03/25 21:00:00</Job.P_UpdateDate>
 </Item>
 ...
</Job>

  

Example 3: Update the phone number in the record whose personal contact information Id is 10001

■Request

Method:POST

.../v1/candidate?partition=1

Request Body

<Candidate>
 <Item>
  <Person.P_Id>10001</Person.P_Id>
  <Person.P_Telephone>0123-45-6789</Person.P_Telephone>
 </Item>
</Candidate>

The “candidate” at the end of the URL indicates that the personal contact information is accessed.

The next parameter “partition=1” indicates that Partition Id accesses the personal contact information in the area 1.

The <Candidate> tag in the Request Body indicates that this data is personal contact information.

The next <Item> is the tag that indicates one record.

Because multiple <Item> tags can be written, multiple records can be updated by one Request. (Up to 200 records)

<Person.P_Id> is the ID of the personal contact information to be updated. ”10001” is specified here.

<Person.P_Telephone> indicates the phone number. ”0123-45-6789” is specified here.

 

■Response

When the processing is successfully completed, “200” is returned to the Response Header as the HTTP status, and the Status Code can be acquired in XML.

Response Body

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Candidate>
 <Item>
  <Id>10001</Id>
  <Code>0</Code>
 </Item>
</Candidate>

 

Implementation Examples

For example, when linking HRBC with your own site, the number of monthly accesses varies greatly depending on how the HRBC API is accessed to display job opening information on the site.

For processing that acquires data from HRBC and displays them on an app, such as a job opening information search, the number of API accesses is likely to become large.

Efficiency should be considered when implementing such processing to minimize the number of API accesses.

*The number of records that can be processed by one Request is 200 for both acquisition (Read) and registration (Write).

 For a large amount of data, 200 records must be processed at a time.

 

For example, in a job opening search on a site, the number of Requests that are made differs between when acquiring the company information and job information together by one JOB Read Request and when acquiring first the company information by Client Read Request and then the job information associated with the company by JOB Read Request.

example-dev1_en.png

 

Note that, for example, when publishing job information on your own site, there may be heavy external accesses to a user app due to the influence of crawling or for some other reasons.

Executing the HRBC API for each access increases the number of accesses.

The design must take performance into consideration, for example, by caching data into the memory of the database or server and periodically acquiring information from the cached data.

example-dev2_en.png

 

Was this article helpful?
0 out of 0 found this helpful