Calling PASI Services

When Integrating with PASI, integrated solutions need to consider audit requirements when Calling PASI Services.

Architectural Considerations

The following questions should be considered when Calling PASI Services.

What is the approach to ensure unique Clien Message IDs are used for all calls to PASI?

If an integrated solution is encountering PASI service call issues, the PASI team will work with the vendor to help diagnose the problem. In order to diagnose the problem, PASI must be able to identify the specific service call(s) associated with the issue. All service calls have a Client Message ID attribute. This attribute is intended to provide a link between a completed service call in PASI and a specific PASI service request from the integrated solution.

An integrated solution must populate the Client Message ID attribute with a unique GUID for every PASI service call and keep a log of all service calls to PASI. This will allow an integrated solution and PASI to quickly zoom in on specific service calls related to the issue being investigated.

What is the approach to populate PASI service request user attributes when the making calls to PASI initiated by a user?

For audit purposes, all PASI service calls request must identify the user that initiated the access and/or update of PASI data. All PASI service calls requests have Caller Info User attributes that must be used to identify the user who initiated a PASI service call. This includes User.Name, User.LocalID, and User.IPAddress.

An integrated solution must populate PASI service request User attributes so the specific user/individual who initiated a PASI service call can be identified.

Is the population of PASI service request User attributes impacted if communication with PASI is interrupted?

Even if communication between PASI and an integrated solution is interrupted, any delayed/queued service calls must still have their request User attributes populated with the specific user/individual who initiated a PASI service call.

What is the approach to populate PASI service request User attributes when the making calls to PASI initiated by a system process?

PASI service calls initiated by an internal process (i.e. Is Data Available service calls) must have their User attributes populated with a generic System Id (i.e. [System Name] Sync).

What is the approach to identify the organization associated with the end user and system who initiated a call to PASI?

For audit purposes, all PASI service call requests must identify the organization that initiated the access/update of PASI data. All service call requests have a Caller Info User Organization attribute that must be used to identify the organization of the user that initiated the PASI service call.

Users may be from:

  • the Government of Alberta (O.1), and have access to all students within the province,
  • a school authority, and have access to all students in all of its schools, or
  • a school user who only has access to students in that one school.

The authority user’s organization code is their authority code and school user’s organization is their school code. The integrated solution must populate PASI service request Caller Info User Organization with the user’s related organization code.

What is the approach to identify Software information when the SIS makes calls to PASI and the approach to identify changes in Software information?

For audit purposes, all PASI service call requests must identify the Software Manufacturer and Product that initiated the access/update of PASI data. All service call requests have Caller Info software attributes in that must be used to identify the Software Manufacturer and Product that initiated the PASI service call. This includes Software.Manufacturer, Software.Product, Software.Version, and Software.BuildNumber.

An integrated solution must populate PASI service request Software attributes. As system changes are implemented, Software.Version and Software.BuildNumber must be populated with the latest information.

How are PASI service Date Time parameters specified when the school authority and/or the SIS server is in a different time zone than Alberta?

A number of PASI services include Date Time request fields however the time portion is not applicable. For instance Identify Student has a request field Birth Date defined as type Date Time but the ‘time’ is not relevant.

An integrated solution must not specify the time and time zone components on PASI service request Date Time type parameters where time is not relevant.

Correct <BirthDate>1970-01-29T00:00:00</BirthDate>
Incorrect <BirthDate>1996-11-19T00:00:00.000-07:00</BirthDate>