This page (revision-11) was last changed on 26-Nov-2021 10:22 by kparrott

This page was created on 26-Nov-2021 10:22 by mmcfarland

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
11 26-Nov-2021 10:22 25 KB kparrott to previous
10 26-Nov-2021 10:22 25 KB mmcfarland to previous | to last
9 26-Nov-2021 10:22 25 KB mmcfarland to previous | to last
8 26-Nov-2021 10:22 25 KB mmcfarland to previous | to last
7 26-Nov-2021 10:22 25 KB mmcfarland to previous | to last
6 26-Nov-2021 10:22 25 KB mmcfarland to previous | to last
5 26-Nov-2021 10:22 24 KB mmcfarland to previous | to last
4 26-Nov-2021 10:22 24 KB mmcfarland to previous | to last
3 26-Nov-2021 10:22 24 KB mmcfarland to previous | to last
2 26-Nov-2021 10:22 646 bytes mmcfarland to previous | to last
1 26-Nov-2021 10:22 647 bytes mmcfarland to last

Page References

Incoming links Outgoing links
WEB SERVICES...nobody
WEB SERVICES

Version management

Difference between version and

At line 3 added 3 lines
[{TableOfContents }]
\\
At line 5 changed 2 lines
__Purpose__//
This service receives information form an external system and loads the employee into Personality, as a new hire or rehire, populating all the pertinent data as noted. \\ \\
!Purpose
This service receives information from an external system and loads the employee into Personality, as a new hire or rehire, populating all the pertinent data as noted. \\ \\
At line 21 changed one line
|LANGUAGE_CODE|Character3|Yes*|Value must be one of the values defined for Language code
|LANGUAGE_CODE|Character 3|Yes*|Value must be one of the values defined for Language code
At line 33 changed one line
|EMPLOYMENT_STATUS|Character 16|Yes|Value must be one of the values that have been defined on the IDES form at the client’s site
|EMPLOYMENT_STATUS|Character 16|Yes|Value must be one of the values that have been defined on the IDES form
At line 46 changed 4 lines
|DEPOSIT1_BANK_ACCOUNT|Character 30|No|The bank account for direct deposit. When the DEPOSIT1_BANK_LOCATION is defined, then this field is mandatory.
|DEPOSIT1_AMOUNT|Number|No|The dollar amount to be deposited into this account each pay. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be provided if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT1_NET_PAY_PERCENT|Number|No|The percentage of net pay to be deposited into this account each pay. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be provided if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT1_PAY_REMAINING|Character 1|No|If any amount is left to be paid into this account, indicate this with a “1” in this field. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be provided if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT1_BANK_ACCOUNT|Character 30|No|The bank account number for direct deposit. When the DEPOSIT1_BANK_LOCATION is defined, then this field is mandatory.
|DEPOSIT1_AMOUNT|Number|No|The dollar amount to be deposited into this account each pay. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be defined if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT1_NET_PAY_PERCENT|Number|No|The percentage of net pay to be deposited into this account each pay. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be defined if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT1_PAY_REMAINING|Character 1|No|If any amount is left to be paid into this account, enter “1” in this field. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be defined if DEPOSIT1_BANK_LOCATION is defined.
At line 51 changed 4 lines
|DEPOSIT2_BANK_ACCOUNT|Character 30|No|The bank account for direct deposit. When the DEPOSIT1_BANK_LOCATION is defined, then this field is mandatory.
|DEPOSIT2_AMOUNT|Number|No|The dollar amount to be deposited into this account each pay. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be provided if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT2_NET_PAY_PERCENT|Number|No|The percentage of net pay to be deposited into this account each pay. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be provided if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT2_PAY_REMAINING|Character 1|No|If any amount is left to be paid into this account, indicate this with a “1” in this field. One of DEPOSIT1_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be provided if DEPOSIT1_BANK_LOCATION is defined.
|DEPOSIT2_BANK_ACCOUNT|Character 30|No|The bank account number for direct deposit. When the DEPOSIT2_BANK_LOCATION is defined, then this field is mandatory.
|DEPOSIT2_AMOUNT|Number|No|The dollar amount to be deposited into this account each pay. One of DEPOSIT2_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be defined if DEPOSIT2_BANK_LOCATION is defined.
|DEPOSIT2_NET_PAY_PERCENT|Number|No|The percentage of net pay to be deposited into this account each pay. One of DEPOSIT2_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be defined if DEPOSIT2_BANK_LOCATION is defined.
|DEPOSIT2_PAY_REMAINING|Character 1|No|If any amount is left to be paid into this account, enter “1” in this field. One of DEPOSIT2_AMOUNT, NET_PAY_PERCENT or PAY_REMAINING must be defined if DEPOSIT2_BANK_LOCATION is defined.
At line 64 changed one line
|CONTACT2_LAST_NAME|Character 50|No|The last name of the second emergency contact. If CONTACT1 information is defined, then both First and Last Name must be defined.
|CONTACT2_LAST_NAME|Character 50|No|The last name of the second emergency contact. If CONTACT2 information is defined, then both First and Last Name must be defined.
At line 80 changed one line
!!Processing
!Processing
At line 86 changed 3 lines
* For a re-hire, IDENTITIES and PERSONALS information are updated, if provided. If the data on the PERSONALS is being updated, the effective date is the HIRE_DATE.
* An EMPLOYMENTS record is created, along with an ASSIGNMENT and ASSIGNMENT DETAILS record.
* The ASSIGNMENTS start date is the HIRE_DATE.
* For a re-hire, IDENTITIES and PERSONALS information are updated, if provided. If the PERSONALS data is being updated, the effective date is the HIRE_DATE.
* An EMPLOYMENT record is created, along with an ASSIGNMENT and an ASSIGNMENT DETAILS record.
* The ASSIGNMENT start date is the HIRE_DATE.
At line 116 changed 2 lines
|-22|Wage Rate defined but rate basis not defined
|-23|Employee State/Prov Code not defined or does not exist within Personality
|-22|Wage Rate defined but Rate Basis not defined
|-23|Employee State/Prov. Code not defined or does not exist within Personality
At line 125 changed one line
|-31|Phone number is not defined for Emergency Contact 1
|-31|Phone number is not defined for Emergency Contact 2
At line 130 changed one line
|-1003|Field XXXXXX is a toggle field where only valid values are “1” or null
|-1003|Field XXXXXX is a toggle field where only the valid values are “1” or null
At line 136 changed one line
|rootURI|This is the domain and port for the web server hosting the Personality REST services e.g. devas2.highlinehosting.com:7833
|rootURI|This is the domain and port for the web server hosting the Personality REST services. Example: devas2.highlinehosting.com:7833
At line 145 changed 3 lines
|Accept|Character 50|Yes|Indicates what format the web service response is, must be set to 'application/json'|application/json
|Content-Type|Character 50|Yes|Indicates what the format of the payload is, must be set to 'application/json'|application/json
|Authorization|Character 50|Yes|OAuth Authorization Token __(see OAuth Security)__|Bearer nnnnnnnnnnnnnnn…
|Accept|Character 50|Yes|Defines what format the web service response is. Must be set to 'application/json'|application/json
|Content-Type|Character 50|Yes|Defines what the format of the payload is. Must be set to 'application/json'|application/json
|Authorization|Character 50|Yes|OAuth Authorization Token (see OAuth Security)|Bearer nnnnnnnnnnnnnnn…
At line 151 changed 2 lines
!!!EMPLOYEE HIRE Inbound to Personality
__Purpose__//
!!!EMPLOYEE HIRE Outbound from Personality
!Purpose
At line 171 changed one line
|TRANSACTION_TYPE|Character 16|Yes|An indicator of the type of transaction that is being transmitted. Data in each group is mandatory, based upon the transaction code here. Options are:\\* POSITION = Position code change \\* GROUP = Group code change \\* STATUS = New employment status, including TERMINATION \\* WAGE = New wage rate
|TRANSACTION_TYPE|Character 16|Yes|An indicator of the type of transaction that is being transmitted. Data in each group is mandatory, based upon the transaction code defined here. Options are:\\* POSITION = Position code change \\* GROUP = Group code change \\* STATUS = New employment status, including TERMINATION \\* WAGE = New wage rate
At line 185 changed 2 lines
!!Processing
The Work Flow module is utilized to trigger the calls to this web service. When an update is made on the ASSIGNMENT DETAILS table of POSITION_CODE, GROUP_CODE, EMPLOYMENT_STATUS or WAGE_RATE, the workflow fires and invokes this web service, passing the information as needed. \\ \\
!Processing
The Workflow module is utilized to trigger the calls to this web service. When an update is made on the ASSIGNMENT DETAILS table of POSITION_CODE, GROUP_CODE, EMPLOYMENT_STATUS or WAGE_RATE, the workflow fires and invokes this web service, passing the information as needed. \\ \\
At line 188 changed one line
Work Flows fire upon the commit of the updated/inserted/deleted data at the database level. If the EMPLOYMENT_STATUS change is one of a defined LEAVE or TERMINATION status, and the date of the transaction is a future date, then no action is taken. \\ \\
Workflows fire upon the commit of the updated/inserted/deleted data at the database level. If the EMPLOYMENT_STATUS change is one of a defined LEAVE or TERMINATION status, and the date of the transaction is a future date, then no action is taken. \\ \\
At line 190 changed one line
A pro-active workflow is executed on a scheduled basis to examine any employees who were put on leave in one of the defined LEAVE statuses or TERMINATED, which takes effect on the date the workflow is executing. All changes are then sent to the receiving system. \\ \\
A pro-active workflow is executed on a scheduled basis to examine any employees who were put on leave in one of the defined LEAVE statuses, or TERMINATED, which takes effect on the date the workflow is executing. All changes are then sent to the receiving system. \\ \\
At line 192 changed one line
!Work Flow UserCalcs
!Workflow UserCalcs
At line 199 changed 2 lines
\\ \\
The workflow example below is executed after each CRUD (create, retrieve, update, delete) operation on Assignment Details, Personals and Contacts calling the appropriate inbound web service into the receiving/3rd party system. Connection details to the inbound web service must be defined on the IMCT form – custom tables admin screen, as shown below.\\ \\
\\
The workflow is executed after each CRUD (create, retrieve, update, delete) operation on Assignment Details, Personals and Contacts, calling the appropriate inbound web service into the receiving/3rd party system. Connection details to the inbound web service must be defined on the Define Custom Tables (IMCT) admin form.\\ \\
At line 202 changed one line
The URL of the inbound service must be defined On the IMCT form in the Custom Data field. The Custom Key and Custom Subkey columns must be defined as follows:
The URL of the inbound service must be defined on IMCT, in the Custom Data field. The Custom Key and Custom Subkey columns must be defined as follows:
At line 218 changed 2 lines
!Pro-Active Work Flow
For Employee status changes dated in the future, which are not handled by the standard work flow, a pro-active work flow must be defined and scheduled to run each day. The UMPWF update process must have the following fields defined.
!Pro-Active Workflow
For employee status changes dated in the future, which are not handled by the standard workflow, a pro-active workflow must be defined and scheduled to run each day. The UMPWF update process must have the following fields defined:
At line 222 changed one line
* User Calc Code: the one that was created in the TMC Personality data base
* User Calc Code: the one that was created in the client's Personality database
At line 232 changed one line
|User Defined Code|Employee is not a valid employee number
|User Defined Code|Employee number is not a valid employee number
At line 239 changed one line
__Purpose__//
!Purpose
At line 250 changed one line
Time systems can send hours as well as an in/out time to Personality. The in/out time is not used, but must be stored for audit purposes. There is an assumption that the Service does not provide rate overrides or position changes during this interaction.
Time systems can send hours as well as an In/Out times to Personality. The In/Out times are not used, but must be stored for auditing purposes. There is an assumption that the Service does not provide rate overrides or position changes during this interaction.
At line 256 changed one line
|TIME_CODE|Character 16|Yes|The time code, as defined by the user in Personality
|TIME_CODE|Character 16|Yes|The time code, as defined in Personality
At line 260 changed one line
|LOCATION_CODE|Character 16|No|If defined, this must be a valid value of locations as defined by the user in Personality.
|LOCATION_CODE|Character 16|No|If defined, this must be a valid location value as defined in Personality.
At line 263 changed 2 lines
!!Processing
As records are received by this web service, they are inserted into the LOADED PAY LINES table with a destination of the IPTR screen, with a status of “To Be Loaded”. Other than the validation that data is in the correct format, no further validation of data is done through this process. Additional validation is done through the Personality UPTR process.
!Processing
As records are received by this web service, they are inserted into the LOADED PAY LINES table with a destination of the IPTR form, with a status of “To Be Loaded”. Other than the validation that data is in the correct format, no further validation of data is done through this process. Additional validation is done through the Personality UPTR process.
At line 270 changed one line
|-1002|Field XXXXXX is a numeric field, but does not contain only numbers
|-1002|Field XXXXXX is a numeric field, but does not only contain numbers
At line 277 changed one line
|rootURI|This is the domain and port for the web server hosting the Personality REST services e.g. devas2.highlinehosting.com:7833
|rootURI|This is the domain and port for the web server hosting the Personality REST services. Example: devas2.highlinehosting.com:7833
At line 286 changed 3 lines
|Accept|Character 50|Yes|Indicates what format the web service response is, must be set to 'application/json'|application/json
|Content-Type|Character 50|Yes|Indicates what the format of the payload is, must be set to 'application/json'|application/json
|Authorization|Character 50|Yes|OAuth Authorization Token __(see OAuth Security)__|Bearer nnnnnnnnnnnnnnn…
|Accept|Character 50|Yes|Defines what format the web service response is. Must be set to 'application/json'|application/json
|Content-Type|Character 50|Yes|Defines what the format of the payload is. Must be set to 'application/json'|application/json
|Authorization|Character 50|Yes|OAuth Authorization Token (see OAuth Security)|Bearer nnnnnnnnnnnnnnn…
At line 292 changed one line
__Purpose__//
!Purpose
At line 305 changed 2 lines
|LEAVE_POLICY_TYPE|Character 16|Yes|This contains the leave policy type as defined in Personality
|AS_OF_DATE|Date|Yes|The date, in YYYYMMDD format, that reflects the time this data was valid
|LEAVE_POLICY_TYPE|Character 16|Yes|The leave policy type. Value must be one of the values that have been defined in Personality.
|AS_OF_DATE|Date|Yes|The date the data is valid from, formatted in YYYYMMDD.
At line 309 changed one line
!!Processing
!Processing
At line 312 changed one line
As mentioned above in the work flow UserCalc section, the IMCT screen holds the inbound URL, user name and password under the custom key LEAVE BALANCE. The fourth sub-key AUTHORIZATION is used to identify the type of security the outbound service uses. USERNAME indicates the user name and password sent in the header of the request.
As mentioned above in the Workflow UserCalc section, the IMCT form holds the inbound URL, user name and password under the custom key LEAVE BALANCE. \\ \\The fourth sub-key AUTHORIZATION is used to identify the type of security the outbound service uses. \\ \\USERNAME defines the user name and password sent in the header of the request.
At line 324 changed one line
|rootUri|This is the domain and port for the web server hosting the Personality REST services e.g. devas2.highlinehosting.com:7833
|rootUri|This is the domain and port for the web server hosting the Personality REST services. Example: devas2.highlinehosting.com:7833
At line 329 changed one line
|Description|In order to call High Line web services, users must first be on-boarded as a Client Application. Once this process is complete, users are provided a Client Identifier and a Client Secret. Users utilize these values to obtain a token to gain access to the web services the user has access to. \\ __NOTE:__ The token is only available for 1 hour (3,600 seconds), after that users must make another call to this service to obtain another token.
|Description|In order to call High Line web services, users must first be on-boarded as a Client Application. Once this process is complete, users are provided a Client Identifier and a Client Secret. Users utilize these values to obtain a token to gain access to the web services the user has access to. \\ __NOTE:__ Tokens have a life span of 1 hour, after which a new token must be retrieved.
At line 332 changed 3 lines
|Username|Client ID (will be provided by High Line)
|Password|Client Secret (will be provided by High Line)
This access token is included in the header of each inbound call to Personality’s web services as shown below under the Authorization key. \\ \\
|Username|Client ID (Provided by High Line)
|Password|Client Secret (Provided by High Line)
This access token is included in the header of each inbound call to Personality’s web services, under the Authorization key. \\ \\
At line 340 changed 2 lines
|Accept|Character 50|Yes|Indicates what format the web service response is, must be set to 'application/json'|application/json
|Content-Type|Character 50|Yes|Indicates what the format of the payload is, must be set to 'application/json'|application/json
|Accept|Character 50|Yes|Indicates what format the web service response is. Must be set to 'application/json'|application/json
|Content-Type|Character 50|Yes|Indicates what the format of the payload is. Must be set to 'application/json'|application/json
At line 347 changed one line
URL’s which have SSL security require the certificates to be stored as an external wallet file that the Personality outbound web services references. The wallet location is defined in the IMCT screen, custom tables.
URL’s which have SSL security require the certificates to be stored as an external wallet file that the Personality outbound web services references. The wallet location is defined on the Define Custom Tables (IMCT) form.
At line 357 added 34 lines
!!!Auditing of Activity
__Inbound logging__ to Personality is captured in the Web Services Logging Table (P2K_WS_LOGS)
* One record for each inbound transaction
* Viewed on the Web Services Incoming Daily Logs form (VWIDL)
* Custom reports can be created to export exceptions
\\
__Outbound logging__ from Personality is captured through Workflow logging and is stored on the Executions table.
* Workflow logging must be turned on (IMST)
* Viewed on the Execution Run Logs form (VMEX/DMEX)
* Reported using RMEX or extracted using print_trace.sql sql script
!!!Time Transaction Flow
The client's interface initiates the transfer of time to Personality, Loaded Pay Lines (IPTL).
* Transactions can be viewed and managed on IPTL
\\
A Personality user processes the Loaded Pay Lines to the Pay Transaction table (IPTR)
* UPTL will transfer the loaded pay lines
* Errors will remain on IPTL and will be reported
* Correct errors and reprocess UPTL
\\
Pay transactions are viewed and managed on IPTR
* Process pay transactions into pay headers for payroll processing (UPTR)
----
![Notes|Edit:Internal.WEB SERVICES]
[{InsertPage page='Internal.WEB SERVICES' default='Click to create a new notes page'}]
This page (revision-11) was last changed on 26-Nov-2021 10:22 by kparrottTop