Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Architecture/Integration Considerations:

All Workday associated hardware and data is housed and supported by Workday.  Custom web service integrations are created and maintained by Cornell staff.  A Cornell maintained, central integration tool (e.g. webMethods or Oracle SOA) should be utilized to facilitate web service integration.

  • Workday uses object models in place of the RDBMS model.  Data is stored in memory. 
    • Need to consider performance, persistence and fault tolerance
    • Tools to access data
  • Central integration tool (e.g. webMethods 8 or Oracle SOA suite). 
    • Avoid point to point integrations and all associated maintenance and coordination that would be associated. 
    • Create an Enterprise Service Bus bridge/repository to support a single view of all Workday web services where policies could be applied
  •  Integrations with our systems:
    • Kronos if it was software as a service: no problem. 
    • Kuali Finance: we'd have to track down all the mapping of their CoA representation.
  • Cynergy: Could we have Inbox items in Workday create notification items in Cynergy that link out to Workday for a single Inbox?  This could easily be done with Events/Notifications from Workday and webMethods/SOA Suite to recognize and create a notification item in Cynergy

Reporting and Service Generation:

...

Workday report generation is dynamic, scalable, customizable and secured

...

.  Workday supports the creation of dynamic, operational reports that can be scheduled, printed, converted to a web service or batch file and file transfered.  Workday supports user-defined calculated fields.  All report data is based on data access privileges.

Web Services are dynamic, customizable and secured

...

.  All data used by a web service is based on data access privileges.

...

 

  • External Systems have their own IDs that register themselves as clients.
    • Workday authorizes the system and the user of the external app to:
      • allow use of the service and
      • get the right data back.
  • EIB: Workday provides outbound flat file generation, select, transform ( Data can be transformed from XML to CSV , or custom XSLT), ship to an SFTP site, encrypt if you want, run or schedule
  • EIB: for high volume loads...
    • SFTP the file, which is a loaded templated spreadsheet, pick up, service called to import it, or upload it manually
    • Ability to set basic error handling manually in defining the upload - # load error limits, validate only load... : errors are based on object validation
    • Error descriptions are added to each error row that failed. 
  • Notifications of automated integrations:
    • VERY extensive integration completion / status reporting - content, trigger condition, recipients, groups, subject, content/body, conditions and rules, with attachments of the file, etc.
  • All events and updates publish the object id, but not the employee id. Any listener of the service (e.g. at CU) has to call back using the object ID to update and/or get more info.
  • Oracle SOA Suite and webMethods:
    • Use these types of tools for governance and standards.
    • Report of the service enabled reports and load the SOA suite repository so they aren't manually synced.
    • Consider calling a service in Oracle SOA suite and use CUWA and then call Workday without CUWA. This is bus to bus.
    • Use if SOA Suite would enable tracking of the use of the services of Workday. Workday doesn't provide service use info. Those usage stats could then tell us which services are actually being used so we  know what to worry about when one side or the other changes (i.e. impact analysis support).

...