- Required Development Skills
- Specifications Overview
- Usage Examples
- Request Examples
- Implementation Examples
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
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.
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.
This API cannot be used to delete data or attachments. Also, currently, no API for deletion will be developed or open.
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.
Example 2: Register the candidate with HRBC
The Candidate API can be called from the app server to register the candidate with HRBC.
Example 3: Acquire the selection situation
The Process API can be called from the app server to extract the relevant selection processes.
Example 1: Acquire all JOB fields information
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.
A list including the attribute information of the field can be acquired in XML.
<Field Count="2" Start="0" Total="1234">
Example 2: Acquire job opening information updated between March 25 and 31, 2015 Japan time.
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.
The XML shown below can be acquired.
<Job Start="0" Count="10" Total="2234">
Example 3: Update the phone number in the record whose personal contact information Id is 10001
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.
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.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
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.
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.