Thinkinginrules has Moved (and other exciting InRule changes!)

Drumroll please!! Picture2

This week we rolled out our revamped, revitalized website at InRule.com! We overhauled the design and updated the content to provide visitors with an enhanced experience when they stop by InRule.com. We hope it proves to be an easy-to-navigate resource for the latest information about InRule Technology and BRMS.

New Website – New thinkinginrules Location!

With the enhancement of the website, thinkinginrules, which features regular updates from our subject matter experts about all things rule-related, has moved. You can find the new blog at: http://www.inrule.com/resources/blog/.

Other Enhancements

The new design incorporates plenty of user-friendly features and streamlined content. We’ve made it easy to locate whitepapers, videos, case studies and other helpful information. The new site also features a more accessible format. Whether on desktop, tablet or mobile devices, site visitors will have access to valuable content to help them gain a greater understanding of InRule Technology, our products and capabilities and the industries, customers and partners we proudly serve.

So….What do you think?

As always, your feedback is important to us. What would you like to see more of? How can we provide you with greater value when you visit www.inrule.com? Share your thoughts with us in the comments below or by emailing rwagner@inrule.com.

Running Business Logic on Demand with Dynamics CRM 2013 Action Processes

Dynamics CRM 2013 supports a new feature that allows developers and configurators to run custom business logic on demand using server-side events. In previous versions of CRM, the server-side event model was restricted to out-of-the-box events such as insert, update and delete events. With CRM 2013, custom events can now be added to the farm to accommodate many new types of custom business processes.

These custom events are defined using “Actions” which are created as “Processes” in CRM. In earlier versions of CRM, Processes could be used to execute asynchronous business logic with workflows. In CRM 2013, a Process can run synchronously if it has been marked as an Action.

Action Processes may prove useful whenever business rules must run synchronously, and on-demand. This new feature provides system integrators a clear path to providing custom behaviors in Dynamics without using some of the painful workarounds required by CRM 2011.

Executing Custom Business Logic on Demand

Once an Action has been defined, it can be used to execute InRule rule requests on demand in two different ways:

  • A custom plugin can be created that calls out to the rule engine. This plugin can be registered to trigger on the new custom event that has been defined in the Action.
  • A custom CodeActivity can be created that calls out to the rule engine. This CodeActivity can appear as a “step” that is authored by a system configurator when creating the Process.

ActionStep900

WorkflowStep900

Triggering Your Business Rules

After the Action Process has been authored and activated in CRM, it can be triggered on-demand using an HTTP call to the Organization Web Service published by Dynamics. Dynamics 2013 includes a new SOAPAction on the Organization Service called “Execute”. The Execute signature takes an event name and a list of input parameters. When this service is invoked, it will trigger any plugins that have subscribed to the custom Action event, as well as trigger workflow steps that may have been authored in the Action Process. Either the plugin or the workflow steps can in turn execute rules and then populate output parameters that will be returned to the caller. Any output parameters are returned to the caller as XML inside of a SOAP envelope response.

A few details to look out for during your implementation:

  • Since the Execute action can be invoked using HTTP, it can be called from the CRM web UI using javascript. However, the javascript will need to handle the complexity of forming and parsing SOAP envelopes.
  • When using plugins with Actions, the output parameters cannot be populated unless the plugin is set to run during a “post-operation”.
  • When using workflow code activities, the output properties for a custom CodeActivity can be set to CRM entity references but cannot be set to output the entire CRM entity.

Software Architecture for Actions Processes with InRule

The following diagrams describe possible software architectures for Process Actions that execute business rules on-demand. Other architectures may also prove useful.

Using Dynamics CRM Online with InRule

This example depicts integration with CRM Online. This approach uses a CRM Online Plugin or CodeActivity to call a Service Endpoint registered with Dynamics CRM. The Service Endpoint is used to marshal a call to a custom Azure listener using the Azure Service Bus.

ActionCloud900

Integration Approach for On Premise Dynamics CRM Servers

This example depicts integration with CRM on premise. This approach uses a Plugin or CodeActivity to call a WCF REST Service to execute rules.

ActionOnPrem900

Report from eXtreme CRM EMEA

shutterstock_141789613_barcelonaLast week I had the opportunity to fly to Barcelona, Spain for the Extreme CRM EMEA conference. The conference brings together Microsoft partners who specialize in implementing Microsoft Dynamics CRM across Europe, the Middle East and Africa. The trip provided a great opportunity to discuss Dynamics CRM and business rules with potential partners in a market I don’t often get to visit. The fact that it got me out of the cold Chicago winter and into the outstanding architecture and cuisine of Barcelona was pretty nice, as well!

The real need for a BRMS arises when the use of CRM coincides with complex scenarios like government benefit eligibility determination, insurance rating/underwriting and product or service upsell/cross-sell opportunities. In the US, we have seen rapid adoption of InRule for Microsoft Dynamics CRM in instances where Dynamics CRM is being used as an application development platform for these types of systems.

I met my UK-based colleague, Colin Parlett, in Barcelona. Colin looks after our partner channel in Europe and he was fairly certain that Dynamics CRM is being used there in much the same way as in North America. The purpose of the trip was to meet a variety of system integrators who work with Dynamics CRM to discuss how they might use InRule in their implementations.

In numerous discussions with partners we learned that, indeed, many Microsoft implementation partners are working on complex implementations of Dynamics CRM. Nearly every person with whom we spoke understood the problems InRule solves and the value it could bring to their clients’ organizations. A great example of this is a company that is building an insurance rating and underwriting system on top of Dynamics CRM. A couple of their people came to our booth for a demonstration. They liked what they saw so much they brought another of their colleagues over. He liked what he saw so much a couple hours later he brought someone else over. Like many others at the event they saw the ability for InRule to resolve some major issues for them and their clients.

The learning went in both directions. I learned that systems integrators in the EMEA region are facing the same challenges as their counterparts in North America. However, a key difference is the degree of vertical specialization. A systems integrator in North America can afford to specialize in government, financial services or healthcare. But in countries like Norway or Belgium the economies are such that the systems integrators feel there is just not enough opportunity in any one vertical. This means a company might implement Dynamics CRM at a bank on one project and then turn around and implement it for the department of corrections on a different project.

Beyond the discussions with partners I saw some great presentations from members of the Microsoft team. Especially interesting was a presentation and panel discussion about how to compete against salesforce.com led by Simon Hutson, a Dynamics CRM pre-sales engineer from the UK. Microsoft is making great strides in winning deals across the globe; especially when it comes to unseating salesforce.com. When a company looks to replace a technology they are highly educated evaluators. Microsoft’s success in this area is a testament to the quality and completeness of the Dynamics CRM product. It is also a leading indicator that more companies will start adopting it for first-time CRM implementations as news of the product’s quality spreads. It’s a great time to be part of the Dynamics CRM ecosystem!

Overall the visit to Barcelona was a great success. We got a variety of partners across the region thinking about how InRule for Microsoft Dynamics CRM can help them tackle some very complex business rules. If you would like to find out more about how the product might help you, please do not hesitate to contact me. I would be happy to speak with you.

Everyday Rule Authoring

Over the years, I have found one of the better ways to hone one’s rule authoring skills is to try and incorporate them into every day utility-oriented activities.  At first, this may appear to be a bit of a reach, since even though you know how to express the logic, it might not always be apparent how to get the rules to actually perform the work.  This is where InRule’s .NET assembly endpoint integration comes into play.

Dlls Are Everywhere

If you think about the sheer multitude of .NET libraries that are available, either native to the framework, commercial, or custom (from CodeProject or similar); somewhere, someone has created a utility to accomplish the very thing that you might be looking to do.  This is undoubtedly the hard part, creating a .NET  assembly to work some level of magic in Windows in order perform a task, such as file management, desktop customization, time tracking or anything else you might imagine.  Maybe the library has a UI and maybe it doesn’t, but more often than not you want to tailor it’s functionality to suit your personal needs, which is where rules can get the job done.

The beauty of accessing these libraries through irAuthor is that right out of the gate you get to explore the methods that are available to you without having to jump into Visual Studio and establish a command line project or test UI.  You can simply point to the library, select the methods of interest and start authoring user-friendly logic against them.  In order to test the desired function, you can launch irVerify and selectively test the methods and view the output.  Therein lies a big benefit; using irAuthor with irVerify as the execution interface absolves the user of having to build a custom UI or custom code to call the .NET library.

Endpoint Definition

So How Have I Used This?

You name it!  In one example, I’ve created a set of file management rules to organize and re-name files based on a number of conditions.  I’m also a music nut, so I tend to get a little carried away with mp3 management using these approaches, but the same concepts apply to a variety of other functions.  There are literally “oodles” of utility-oriented tasks that I either manage via rules or are on my to-do list to implement.  I’ve used rules to manage ID3 settings, normalize tracks, download artist and album information, and even auto post to blogs.  The basic example below cycles through an Album directory and pre-fixes the file name with cd1_ cd2_ in a multi-disc scenario (old school I know), but the point is I did not have to write an application to manage this and was able to leverage the .NET framework mscorlib.dll directly through irAuthor.

BLRule

Ok, I’ll Come Clean

Invariably, when you try to do this the first couple of times for non-trivial operations, you may run into a technical situation that doesn’t necessarily have an obvious approach for how to handle.  This could be caused by methods that require non-primitive types, array-based return types, dependencies on other dlls, and so on.  That being said, after you resolve a few of these “devil in the details” scenarios, you begin to develop a toolset (both experience-wise and build-up of InRule technique) for handling this complexity.  Depending on the library you’re working with when you encounter an issue you may be able to resolve it by applying an advanced authoring approach or in the extreme case, by creating a lightweight wrapper dll or “shim” that can expose friendlier custom methods that shield much of the underlying noise.

If You’ve Made It This Far…

Maybe you’re willing to go a bit farther (name that movie).  After getting a few of these utility apps under your belt, the ideas will start flowing in and before you realize it, you might be delving into anything from personal financial calculators to rule-based home automation and web-based information aggregation.  You may even notice that some of the patterns will apply back to your “real” InRule work and suddenly your next rules-based business process might not seem so overwhelming.

Better Living Through Continuous Improvement, Part 2: Team Principles

Continuous Improvement for Teams

In a previous post, I introduced the two principles by which I try to live:

  • Always Get Better
  • Strive for Excellence, Not Perfection

I then focused on how to put those principles into practice from a divisional perspective. In this post, I’ll address on how to put them into practice in a team environment.

Continuous improvement is most easily accomplished at the team level. At InRule Technology we utilize a number of different approaches to enhance the team. I’m sharing a few that the Engineering team has found most effective.

Lunch and Learn

I’m a firm believer in learning about things beyond core competencies. It’s easy – especially in the software industry – to find yourself left in the dust if you don’t actively keep up with the latest technology. As an ISV, it’s especially important for us. We need to be aware of what’s happening in the industry to make better decisions.

Every Friday we have lunch delivered and watch a video related to software development – but typically not anything we’ve done before or have expertise in. This expands our horizons and helps us think about “what’s next” with a more enlightened perspective. InfoQ is a great resource for material covering all of the technologies in play today and they frequently post presentations from recent conferences. For Microsoft material, MSDN’s Channel 9 is our go-to spot to get the latest on what’s coming out of Redmond.

Book Club

Some foundational information is so important that everyone needs to have a firm grasp of it. As a business rule engine company, we touch a wide range of technologies and need to have a solid understanding of the inner workings of the frameworks on which we build our software.

Last year we started a book club and spend 30-60 minutes once a week talking about that week’s readings. It’s a great way to get everyone on the same page and be sure that everyone has a shared understanding of what’s important. Our first book was Jeffrey Richter’s CLR via C#; a must-read for all .NET developers.

Yammer

Yammer bills itself as the “Enterprise Social Network.” Indeed, it’s very much like Facebook for businesses, allowing access to only those that share the same email address domain (@inrule.com, for example).  Yammer allows everyone to share things that may be useful/interesting with others, share ideas and get feedback. It’s also a good place to share non-work related items of interest.

As part of the process

Process is all around us, whether it’s tightly managed or borderline chaos. Embracing continuous improvement at this level allows the participants to control their destiny.

We use agile methodologies for our software development and utilize “sprint retrospectives.” A sprint is a fixed amount of time in which we plan and execute our work. We work in two-week sprints. At the end of each sprint, the team gets together and discusses what went well and what could be improved. Considering the short length of the sprints, it’s a great opportunity to reflect on the past couple weeks and make adjustments . Unlike methodologies like Waterfall that end with a long list of “lessons learned” and promises to “do better next time,” retrospectives allow the team to get better in near real time, increasing trust with stakeholders and providing a more predictable environment.

Making it work

The number one way to benefit from continuous improvement is to embrace it. Make it happen. Believe in the motivation and long-term benefits – because they’re real.

It’s easy to start initiatives, but it takes effort to continue them. I’ve heard countless stories of managers kicking off initiatives only to put them on hold soon thereafter due to time constraints and the like. And you know how that goes: They die on the vine. And people lose faith.

If you do a lunch and learn, keep them going, even during time crunches. If you do retrospectives, make an honest effort to address the problems that are brought up. The more faith people have in the process, the better the process can become, which results in a happier, more productive team.

And at the end of the day, keeping smart people smart and engaged makes for a happy workplace. Isn’t that motivation enough?

Turning the Tables on Rule Creation

Put Your Information to Work

In the world of application development, requirements are stored in a variety of ways. As somebody who helps InRule customers implement our technology, I’ve seen great documentation and…well…some that’s not so great. Regardless of the quality though, one trend that we see is people leveraging Microsoft Excel to store requirements. Why not, right? It’s portable and a great way to organize information in a meaningful and structured format.

But how do you take this wealth of static information and transform it into actual rules that can be used by your application?

In most cases, rule authors manually work through the spreadsheets to build those rules one-by-one. Unfortunately, this sometimes ends up being the most practical solution when you have variations in the requirements or in the desired rule output. However, if your spreadsheet data follows a fixed pattern and you are willing to write a bit of code using the InRule SDK, this information can be leveraged to automate the process of building rules. This approach not only saves time up-front when building rules, it also ensures consistency in the generated rules, as well as minimizing future rework.

Great! So how do you do it? Enter irAuthor Extensions!

Extensions in irAuthor

Simply put, an Extension is a .NET assembly that implements specific interfaces and leverages the rule authoring framework exposed by the InRule SDK. The concept is very similar to a plugin. And like a plugin, an Extension gives you the ability to customize the rule authoring experience to meet your specific rule authoring needs. Any of the following can be accomplished with an irAuthor Extension:

  • Change the behavior of existing features
  • Add new features or functionality
  • Remove features you want to hide from your rule authors

In this example, our extension will add a new button to the irAuthor ribbon that will allow you to browse for a spreadsheet and import it as a Decision Table into your rule application.

extension

Where Do I Start?

In this example, the Extension will import data from Excel spreadsheet to build a Decision Table in the rule application. The following spreadsheet has been used to determine if the established premium for the insurance policy in a given State or Province is sufficient. If it is not, the policy is invalid.

spreadsheet

First, you need to determine which column(s) in the spreadsheet will be evaluated as conditions and which column(s) define the action(s) the rule should execute. This concept maps directly to the Decision Table construct, which is comprised of two parts, Conditions and Actions.

In this example, the first column in the spreadsheet holds the value for the State/Province. Each unique value that appears in that column should be created as an option in your State/Province condition. The screenshot below shows what that condition would look like in irAuthor: the condition has a recognizable name, maps to a field in the authoring model, and consists of all of the valid options the rule author can then select.

condition

Once you’ve created your first condition, the remaining spreadsheet columns, Limit and Base Premium, can be handled in the same way.

Next, you need to add your Actions. While a Decision Table can support multiple Actions, in this example, there is only one called “Invalid”. The Actions are built in a very similar manner as the Conditions. The Action will simply mark the entire policy Invalid when the premium is too low.

action

The final step is to build the rows in the Decision Table using your Conditions and Actions. Each spreadsheet row will map to a row in the Decision Table. At execution time, when all of the Conditions in a row evaluate to true, the Action will execute. Once you have created all of the Decision rows, the Decision Table is complete and, as you can see below, it looks very similar to the spreadsheet, except that it can now be consumed by your application.

decisiontable

“Extending” An Offer

We touched on just one of the capabilities that you have at your disposal with the InRule SDK and irAuthor Extensions. Whether you want to add a new window into irAuthor to provide alternate ways to view your rules or replace existing functionality with some of your own, irAuthor Extensions allow you to customize your authoring experience to meet your needs.

I encourage you to download a free trial of our solution. In addition to the software, you also get access to the InRule Support site, which contains additional information on how to build an irAuthor Extension as well as working samples in our Extension Exchange library. Each sample contains an explanation of what the Extension does as well as the source code.

If you have any ideas for irAuthor Extensions that you would like to see added to the Exchange, please let us know by commenting on the post.

Better Living Through Continuous Improvement

In the mid-90s I was both a finance student in college and an intern at Merrill Lynch, so Steven Covey’s Seven Habits of Highly Effective People was required reading. As a 20-year-old, I didn’t have a full appreciation of many of the habits. That’s especially true of the seventh habit, Sharpening the Saw.

7 Habits is about personal effectiveness. Within that context, Sharpening the Saw refers to eating well, exercising, restoring, learning, reading, writing, teaching, and expanding the spiritual self. A similar approach can be taken by organizations, from large corporations to small teams. I’ll be using examples from our Engineering group at InRule Technology throughout this post.

Principles

I’m a simple guy and try to live/lead by two simple principles:

Always Get Better

In the film adaptation of Mamet’s “Glengarry Glen Ross,” an aggressive Alec Baldwin orders a lackluster sales group to Always Be Closing (ABC). While that may work in a sales organization, I like to think in terms of AGB: Always Get Better. The world is always changing, and with it the environment in which every organization operates. There are always opportunities to get better. This is a true win/win, as both the organization and individual benefit.

Strive for Excellence, Not Perfection

At the same time, perfection should not be the goal. Perfection is largely subjective – and a moving target at that.  The joy is in the journey and expecting perfection leads to disappointment, over and over again. (Remember what Einstein said about that?)

Principles in Practice

I like to think in terms of scope: organizational, divisional and team. Each presents different opportunities with regard to improvement. As managers we have most influence on divisional and team principles. In this blog post, I’ll address divisional principles. I’ll dive into team principles in a future post.

Divisional

Here is where continual improvement can be more easily realized, as those that are affected by it have access to the means by which it can be improved.

At InRule Technology, we often have quarterly goals, chosen by the leaders of each group. The Engineering group typically uses these opportunities to make changes to our process over time. For example, this quarter’s initiative involves a major revamping of our build process.

The Engineering group also takes one day out of the month to address two things: Friction and/or Technical Debt.

Friction

Merriam-Webster defines friction as:

  • the force that causes a moving object to slow down when it is touching another object
  • disagreement or tension between people or groups of people

Within our group, Friction is anything that slows us down or, frankly, is irritating. We maintain a Friction Reduction board in Trello that anyone can add issues to when they come upon something that is frustrating or slows them down.  During Friction Reduction Fridays, the entire team works on addressing these issues, which are typically operational.

Technical Debt

Wikipedia defines Technical Debt as “… [a] metaphor referring to the eventual consequences of poor software architecture and software development within a codebase.”

Our Technical Debt Reduction Days allow our engineers to address issues that otherwise might not get prioritized. We also have a Technical Debt Trello board that may be added to at any time, as well as TechnicalDebt attributes that decorate code that’s known to have debt.

The Impact

Friction and technical debt reduction empowers team members to document what they believe to be wrong – and fix it.  These practices empower individuals and make them accountable to Always Get Better.  Employing these practices foster a culture in which there is a vision of excellence—not unattainable perfection—that everyone strives for, as individuals and as teams.  With individual and shared visions of excellence and a desire to continually improve, it’s a joyful and productive journey.

Next time: Principles in Practice for teams