Versions Compared

Key

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

...

Architecture/Integration:

  • All Workday associated hardware is housed and supported by Workday.
  • Workday uses object models in place of the RDBMS model.  Data is stored in memory. 
    • Need to consider performance, persistence and fault tolerance
    • Tools for 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
  • Access to Workday developer community site
    • Review Workday web service list, especially the 'Integration' web services with the high level 'cloud' service integrations.
  • SPML - http://en.wikipedia.org/wiki/Service_Provisioning_Markup_Language
  • SAML/Shibboleth support
  • 'cloud esb offering' = client downloads the tools and does their own integrations to be validated and deployed by Workday in the cloud. Two clients are doing this in 'beta'.  Not really meant for customers that have their own integration tools, such as webMethods or SOA suite.
  • Integrations  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.
    • Cornell should consider a portal to aggregate different "Inboxes" from the different systems.
  • Cynergy considerations:  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
  • Web Services: https://community.workday.com/api

...

Reporting and

...

Service Generation:

  • Reports:
    • You can define calculated fields at report time.
    • Report writing lets you make reports based on the access you have. Then save, schedule, share, or make as a web service. 
  • Services:
    • Making web services requires specific permissions.
    • You can search through reports and see which are shared and which are web services.
    • Using the services and reports - as a human or as an app - requires privs too. You get the data relevant to your privsprivileges. Data relevance is based on privileges.
    • External Systems have their own IDs that register themselves as clients.
    • Workday authorizes the system and the user of the external app to a) :
      • allow use of the service and
      b)
      • get the right data back.
  • EIB: outbound flat file generation, select, transform (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, and then they pick it up and call a service picked up, service called to import it, or upload it manually
    • set  basic basic error handling manually in defining the upload - # load error limits, validate only load... : errors are based on object validation
    • the error description is 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:
    • They would like to see more clients using these types of tools for governance and standards. few do.
    • We would make a report of teh service enabled reports and load the SOA suite repository so they aren't manually synched.
    • We could have all clients of Workday call a service in soa suite and use CUWA and then call Workday without CUWA. This is bus to bus (I think - SL).
    • 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).

...