Explain Workday architecture services

Explain Workday architecture services Workday has expanded its services to support and add new features to larger customers. The initial few services developed into multiple discrete services, each focusing on a particular function. By viewing a diagram that includes those additional services, you can get a deeper understanding of Workday 's architecture. This more detailed diagram of architecture presents multiple services grouped into districts.

These services connect through a variety of different routes. A representation of those connections is more like a city map than a traditional software architecture diagram. There are districts with distinct characteristics just like any other city.

UI services There are a variety of iconic facilities familiar to local Workday residents. Staying with the metaphor of the city, users approaching the UI services through Workday Way before having their requests handled by the Transaction Services. The API Gateway offers programmatic access to a Transaction Service.

Alongside a relatively new landmark, the familiar Business Data Store is clearly visible: the Big Data Store where customers can upload large volumes of data for analysis. HDFS is the basis for the Big Data Store.

Workday’s Operations team uses the Wave front-based monitoring console to monitor the city's health and performance.

User Software Interface Zooming into the district of the User Interface helps us to see the many services, which support the UI of Workday.

The original UI service is still in place, which handles all requests created by the user. In addition, the Presentation Services offer a way for clients and partners to extend Workday's UI. Workday Learning was our first service to use content extensively. These large media files host on a content delivery network, which provides our users around the globe with efficient access. Worksheets and Workday Prism Analytics have also introduced new ways to interact with the Workday UI. Clients who use these features interact directly with those services. These UI services collaborate via Redis-based Shared Session service. This gives users a seamless experience moving between services.

Development geared to metadata This architecture also illustrates the value of building enterprise applications using metadata-driven development.

Workday applications designs and implements application developers using XpressO. Then you can run it on the Transaction Service. The Transaction Service will respond to requests by providing data as well as metadata. The UI Services select the appropriate layout for the client device using the metadata. You can use JavaScript-based widgets to display certain data types and give a wealth of user experience. This separation of concerns isolates developers from UI considerations in XpressO. It also means our JavaScript and UI software developers will concentrate on developing the components at the front-end.

This approach has allowed Workday to change its UI radically over the years while providing consistent user experience across all of our applications without having to rewrite application logic.

The Services for Object Management The Object Management Services started life as a single service that we now call Transaction Service.

The OMS has grown over the years to become a range of services that control a customer's data. A brief history lesson outlining why each service we introduced will help you understand its purpose. To view, each service is added to the architecture.

Originally, there was only the Transaction Service and a SQL database, which stored both business data and documents. As document volume increased we introduced a dedicated Nosql-base Document Store.

Larger customers brought in a lot more users and increased the load on the transaction service. As a way of reducing the load, we implemented Reporting Services to manage read-only transactions. Such services also serve as databases in memory and will load all data on startup. For both the Transaction System and the Reporting Services, we implemented a Cache to enable successful data access. By moving indexing and search features out of the Transaction Service and into the Cache, more efficiency.

Subsequently, the Reporting Systems expands to support external activities such as payroll estimates and activities operating within the job system.

Searching is an important part of working day user interaction. The most prominent search feature is the global search box, which provides access to indexes across all customer data. Prompts also provide search capabilities for the data entry support. Some prompts make hundreds of thousands of values accessible quickly. Using cases like recruiting present new challenges as a search can match a large number of applicants. Sorting out results by relevance is just as important in this scenario as finding out the results.

A new Elastic search based search service introduces it to scale the service out and address these new usage cases. This new service replaces the search engine based on Apache Lucene, which co-located with the Cache. A machine-learning algorithm that we call the Query Purpose Analyzer constructs

models based on data from an individual customer to enhance both the matching and the pertinence ordering of the tests.

Scaling up the Object Management Services is an ongoing mission, because we are expecting more and more clients. For example, more of the load from Transaction Service is spread to other services.

Reporting Services now support update tasks, with activity coordinated by the Transaction Service. We are currently constructing a fabric based on Apache Ignite which will sit next to the Cache. We will be moving the index functionality from the cache onto the fabric during 2018. The cache would eventually be replaced by identical applications running on the fabric.

Inclusion Services Workday manages integrations, and they are deeply embedded in our architecture. Integrations use the API Gateway to access the Transaction Process and Reporting Tools.

The Transaction Service manages the integration schedule. An integration can be implemented on the basis of a schedule, manually by a user, or as a side effect of a user-led action. The Integration Supervisor, implemented in Scala and Akka, manages the network of compute resources used to implement integrations. It identifies and deploys the integration code to a free tool. Through invoking a report as a service or using our SOAP or REST APIs, the integration collects data via the API Gateway. A standard integration process will convert the data into a Comma Separated Values (CSV) or Extensible Markup Language (XML) file and deliver it using the Protected File Transfer Protocol (SFTP). The Integration Supervisor will store a copy of the Documents Store file and audit files before freeing up the compute resources for the next integration.

Persistence services There are three main solutions used for persistence within Workday. The software offers features that are unique to the type of data it stores and how it processes the data.

Business data is stored in a SQL database that supports tenant management operations like backup, disaster recovery, tenant copying and point-in-time data recovery.

Documents are stored in a NoSQL database which provides a distributed store of documents and recovery of disasters. The Data Storage Gateway offers functionality for linking the NoSQL database to other Workday systems. This offers encryption at the tenant level and connects the documents to the business data to ensure careful handling of documents during tenant management operations.

Big data files that our customers upload are stored in HDFS. The presumption here is that customer loaded data will be so big that it will need to be processed where it is stored, as opposed to being transferred to where the computing resources are located. HDFS and Spark offer the necessary capabilities to process the data in this way.

A number of other persistence solutions across the Workday architecture are used for specific purposes.

Some of them stand out in the diagram above: Statistics about performance are stored in HDFS. Notice that this is a separate HDFS installation to our Big Data Store that is also HDFS based.

Within Elasticsearch the diagnostic log files are stored.

Using Elasticsearch, the Search service supports global search and search within prompts.

The Integration Manager maintains an application queue inside a MySQL database Some user-created spreadsheets are stored in a MySQL database.

UI Services access data from a Redis in-memory cache to the Shared Sessions. The OMS services also use a Redis cache to manage user sessions and coordinate some tenant-level activities.

Media Content is stored in Amazon S3 for products such as Workday Learning.

All of these persistence approaches often adhere to Workday policies and procedures related to restoring, recovering, and encrypting tenant data.

Conclusion I hope you reach to a conclusion about Workday services. You can learn more through Workday online training.

Ph No: +91- 9550102466, E-Mail ID: info@onlineitguru.com