inrule saas overview€¦ · inrule saas overview 3 312.648.1800 why use inrule as a service? the...

InRule SaaS Overview

Why use InRule as a Service? 3

Where are the capabilities located? 3

SaaS Topology by component and disaster recovery 5

Executing rules 6

Security and centralized authentication 10

Advanced Topics 10

Persisting metrics 10

Batch processing 11

Simulation 12

Contents

3INRULE SAAS OVERVIEW

312.648.1800www.inrule.com

Why use InRule as a Service?The purpose of this paper is to answer common questions about the InRule SaaS offering Moreover, the salient differences between SaaS, on-premises, and self-hosted deployments are broken out To begin, let’s focus on what’s in the SaaS offering specifically.

The InRule SaaS offering hosts the server-side components of the Decision Management Platform for you in the cloud This allows you to focus your initial project efforts on goals, team building, requirements discovery, and rule authoring Your integration efforts can easily connect using REST APIs and rely on industry standards for security and authentication

Here are some of the key reasons and features that drive interest in our SaaS offering:

• Lower your TCO by not managing infrastructure and updates. The SaaS offering relieves the team from activities that would otherwise siphon hours from IT resources

• Scale and grow with your business. With the SaaS offering you can easily add environments and execution cores where needed InRule monitors your environment and lets you know if you are approaching limits

• Publish decisions from irAuthor with customized URLs and versioning. Manage revisions in irCatalog and deploy using conventions that make sense for your project and promote best practice

• Rapidly discover and try REST APIs based on Swagger. irServer customers can test REST end points using the Rule Execution Console which is only available from the SaaS offering

• Cross-platform support for strongly-typed REST APIs in JSON using Decision Services. Customers that already integrate to irServer via REST can continue to use loosely-typed REST APIs in JSON and XML

• Authenticate server-to-server with centralized security and Azure AD support using Decision Services. irServer REST APIs authenticate with API keys over SSL

• Centralized logging of deployed components (App Services) aggregate in Azure Storage for easy access. Analyze your logs by exporting and/or using a third-party tool

• Manage your team and rule applications from Web Catalog Manager, which is integrated with the SaaS portal

Where are the capabilities located?The design-time components irAuthor and irVerify install locally on the rule author’s workstation just like other productivity applications, such as Microsoft Office. Once installed, rule authors write and publish their work to the cloud for governance using a hosted instance of irCatalog

irCatalog controls versioning, security, promotions, and lifecycle statistics to the SaaS portal When rule applications are called via a REST endpoint, the rule application is retrieved from irCatalog, compiled, and executed on behalf of the consuming application Your team will focus on writing rules and publishing and calling the REST APIs as your integration activities kick-off Figure 1 maps capabilities to specific products and where they are deployed:

https://www.inrule.com



Keep in mind that consuming applications can be either in the cloud or on-premises This is especially helpful when you have to migrate applications a little at a time If you are not familiar with InRule components, take a look at this quick reference:

• irAuthor is the rule authoring experience that runs on your local workstation like Microsoft Office. It includes irVerify which is the primary experience for rapidly testing rules We believe InRule has the most efficient change/test experience in the industry.

• irCatalog is the rule repository that manages the rule lifecycle It controls versioning, team sharing and enforces security Web Catalog Manager is the web experience for managing the services provided by the irCatalog

• Portal is the primary web experience for managing the deployment of rule applications, managing your team and configuration of the SaaS environment.

• Decision Services provides strongly typed REST services endpoints for rule applications It also includes Swagger descriptions of published services

• irServer provides metadata-oriented REST calls in XML and JSON for rule application execution with entity state passed as a String Rule Execution Console is used to discover irServer REST endpoints

• Metrics is an out-of-the-box solution for selectively saving off instrumentation data to track progress on business goals and KPIs

» Figure 1




SaaS topology by component and disaster recoveryThe graphic below provides a high-level topology diagram of a single SaaS environment:

The following points should be noted:

• The SaaS offering provides multiple service levels to match your risk requirements

• SaaS environments deploy to a single region in Azure. InRule works with its customers to provide the service in the region that most closely aligns with application performance and regulatory requirements Customers can request failover environments in other regions dictated by Azure options

• irCatalog instances are redundant in development environments where all rule authoring is taking place Rule applications are promoted to other catalog instances until they reach the “Production” environment

• irAuthor makes rule applications available to a runtime by publishing to the catalog. irAuthor is responsible for publishing to Decision Services Administrators are able to shape and deploy decision services independently of irCatalog This allows for more

» Figure 2




flexibility to follow best practices. REST APIs are available for customers to orchestrate their own DevOps processes and automate the publish process for improved governance

• Execution scales to the number of cores purchased. Performance is different for every customer because of the unique amount of data submitted to a decision and the algorithmic complexity represented by the logic in the rule application InRule will help with sizing your environment

• Centralized logging is available from a secure URL hosted in Azure Table Storage. SaaS instance administrators receive a secure URL for read-only access into logs While it’s true that InRule monitors your SaaS environment, exceptions can still occur based on rule content and should be monitored from time-to-time

Executing rulesExecuting rules within the SaaS environment is similar to InRule on-premises and self-hosted cloud instances; however, there are currently features only available from SaaS noted in the chart below

At a lower level, execution of irServer remains relatively unchanged The addition of Decision Ser-vices, however, moved the product away from Windows Communication Foundation (WCF) and embraced ASP NET Core for the services layer

Decision Services uses its own storage for execution and is not directly connected to irCatalog by design This separation of concerns allows administrators to have more control over service deploy-ments and configuration.

Calling the REST APIs between irServer and Decision Services demonstrates the dramatic differ-ences in the signatures. Configuration metadata decorating the body of the messages have been removed, leaving only the strongly typed entity state in the body irServer also requires the entity state escaped and passed as a String adding over-head to the integration tasks

» Figure 3




Strongly typed decisions, while using Decision Services, can be discovered using Swagger/Open API:

» Figure 5

» Figure 4




Resources

Swagger: https://swagger io Open API: https://swagger.io/specification/

As for irServer, the integration is straightforward Entity state is passed into the decision, including all configuration metadata for end points, logging, and notifications. You can explore the options while using Rule Execution Console from the SaaS portal Click “Test” from the menu at the top of the portal Select the rule application you want to test Enter the entity state you want to pass and then click “Apply Rules” at the bottom of the form:

Keep the following in mind when integrating with the SaaS offering for the first time:

» Figure 6


https://swagger.io

https://swagger.io/specification/



• Explore Decision Services using Swagger. Use the Swagger URL to explore published decisions

• irServer connectivity requires an API Key. Log into the portal. Click on “Configuration” from the top menu. You will find the key in the “Execution” heading on the page along with the specific URLs for the type of calls you want to make. The URLs are slightly different depending upon the type of rule set you want to call Examples are also provided for each rule execution pattern supported by the engine

• Database and REST end points are supported in SaaS. Keep in mind that connectivity within Azure requires network level connectivity to be configured for all IP traffic between workstations (irVerify) and the SaaS instance It’s possible that your workstation IP address is different when browsing the Internet Use a website to discover your external workstation IP address

• SQL Query and REST endpoint results support caching. Caching of results improves performance for static data and can be controlled by configuration within irAuthor. Read about this topic and more from irAuthor help or the InRule support site (https://support inrule com)

» Figure 7


https://support.inrule.com

https://support.inrule.com



Security and centralized authenticationThe SaaS offering supports centralized authentication for Azure AD and any other OpenID imple-mentation Management and execution APIs for Decision Services require token-based authenti-cation based on the OAuth 2 0 protocol For example, while using Swagger, it’s easy to see the authentication in action:

Things to note in general about InRule’s SaaS security:

• All communication taking place in the SaaS environment is encrypted with support for TLS 1 2

• InRule security policy follows the ISO 27001 standard

Advanced TopicsPersisting Metrics

During on-boarding of your SaaS instance, you will be asked about metrics and where you would like them persisted. At the time of the paper, self-service configuration of metrics storage is not available but is fully supported in the SaaS environment Once your persistence is set up, based on one of two providers (Azure Table and Storage, SQL Server) While there is a third provider for CSV it’s not appropriate for a cloud environment

RESOURCES

GitHub Repo for Providers: https://github com/InRule/InRule Runtime Metrics Practice for Using Metrics: https://www inrule com/resources/blog/good-beginnings-thinking-in-metrics/

» Figure 8


https://github.com/InRule/InRule.Runtime.Metrics

https://www.inrule.com/resources/blog/good-beginnings-thinking-in-metrics/



Batch processing and simulation

Batch processing with your SaaS instance is fundamentally the same as on-premises You have to decide for yourself what is a reasonable window for the work to complete, then work backwards from that SLA to a configuration that works.

Basic Batch

Using whichever programming language you choose, you need to do three things for basic batch processing:

1) Connect to your data

When connecting to data in the first step, you might need to transform your data to a JSON format compatible with your decision signature Ideally, your data is already in JSON format and conforms to your entity schema No-SQL approaches tend to work well since no time is required to marshal impedance mismatch between your data at rest and what’s required for Decision Services MongoDB and Hadoop are great ways to think about running large batches with minimal transformation

2) Call Decision Services

Establish your authentication token and setup your HTTP POST in code If you are using an ETL tool, make sure it supports the features required for Decision Services

3) Persist the results

Place the results of the batch in a data store that’s reachable for reporting and analysis That’s it

Performance remains a constant consideration with batch processing Excessive data serialization and transport will add a tax onto every execution of your decision The general principles are to keep the data as close to the decision as possible and minimize serialization Keep in mind that InRule executes natively on many platforms and there are times when extreme scale requires re-thinking the basics

» Figure 9




Simulation

Simulating outcomes for “What If” analysis follows the same patterns for batch processing While a batch might change production data, simulation is typically batch processing against data that’s been staged specifically for the purpose of analyzing outcomes, forecasting, and measuring impact on KPIs Running effective simulations requires investments in data management, analytical tooling, and a working rule application Putting this all together in the cloud makes a lot of sense and we are happy to work with you

Above all, if for some reason you get stuck on a performance question, reach out to one of our experts. We will gladly walk you through the options and help you find the best architecture that fits your requirements and constraints.

If you have comments and thoughts about this paper, please let us know – info@inrule com


mailto:[email protected]

inrule saas overview€¦ · inrule saas overview 3 312.648.1800 why use inrule as a service? the...

Documents