dinsdag 31 oktober 2017
For all of you who have been struggling with how to interact with their cases, there is good news. Since 12c, Oracle has created a REST API for Adaptive Case Management (ACM):
Since the API is pretty much self-explanatory and fairly easy to use, I will not write a lot of detail about it (at least not right now, maybe later). However, I think that those of you who are struggling with the Java API or something custom made will definitely find something much easier to use here, for both integration and testing. Since most blogs about the subject have been written before this REST API became available, I thought it would be good to draw people's attention to this.
woensdag 10 mei 2017
In my previous blog, I showed how to get started with Decision Model Notation (DMN) in Oracle Process Cloud Service and how to create a simple Decision Table. Picking up from there, we will now look into creating If-Then-Else rules, which should also be familiar to people who know Oracle's old Business Rules. We will also create a service and call it from a process.
Creating an If Then Else DecisionAs Input, I have created a TotalAmount object, which is the total amount of a Sales Order. Based on this TotalAmount, we are going to calculate a Discount Price, for which I have created a DiscountPrice type to make the service interface a bit prettier than just 'output'. To create an If-Then-Else rule, just click the + button next to Decisions, enter a name and set the output type to string, number or any other type, in this case DiscountPrice.
Now, Oracle will have created a rule for you, in which you only need to fill in the "if", "then" and "else". Since you've already decided your output object, we will not use that one in the expression, which is different from the old Oracle Business Rules. So just enter the value that you want for this object and you'll be fine. You can also create nested expressions, as shown below:
One thing that I don't like, is that all the nesting needs to be done in the "else" part. I hope for Oracle to acknowledge this and create a new "if" section (for example with indent), where I can happily nest away in a more user-friendly manner. However, it works (use the Test feature to verify) and if you don't make things too complicated, it's mainly a minor display issue.
Calling an If Then Else DecisionCalling any Decision from a process is super easy. Just make sure to have a service created for your Decision and deploy it, so the process can find it. In Oracle Process Cloud's Process Composer, you can then select "Decision" as a system task, select the Decision Model that you want to use and the service within that Decision Model that you want to call:
From here, you can make your data associations and you're done. Obviously, a process is generally not as simple as this one, but using Decisions within processes is.
So that's the second part of this blog series. The third part will be an overview of other DMN functionality: Expression, Relation, List, Function and Context. I still think that we will mostly be using If/Then/Else and Decision Tables though, so for most use cases, the information in this blog and the previous one should provide you with a nice kickstart.
maandag 8 mei 2017
Recently, Oracle Process Cloud Service (PCS) has made another major step forward through the addition of a whole new way of dealing with business rules. This brand new Decision Model Notation (DMN) feature is developed seperate from the actual processes and deployed as a microservice, so your decision models can be reused and everything is nicely loosely coupled. I like it.
What I also like about DMN is that it's much more (business) user friendly than the rule engine from Oracle SOA Suite, which was used until now. While it was performing well and somewhat agreeable for technical users, business users were often lost and leaving the business rule modelling to developers. With this new DMN feature, this is no longer necessary. Business users will be able to do much more, if not everything, themselves and actually enjoy the experience!
I've decided to write a series of blogs about the different types of decision models that can be created and how to use them. But first we need to turn it on.
Getting StartedWhen you're in the home screen, click on your login name in the top-right corner and choose 'Administration'. On the Admin page, go to 'UI Customization' and tick 'Enable DMN in Composer', then Save.
Creating a Service
woensdag 29 maart 2017
"You don’t want to become an Oracle SOA developer, for two reasons: SOA and Oracle."
Quite a powerful statement, so let's dive deeper into the two reasons mentioned above and explain why I strongly disagree with mr. Vesterli.
First of all, he makes a rightful claim that SOA has over-promised and under-delivered for a decade. I share this feeling, but I do not believe in the bleak picture of the future of SOA that he is painting.
Of course, we can now jump into microservices, which are at the peak of inflated expectations and doomed to fail in their own way with all the downsides and requirements that they have, or we can adjust our perspective on SOA and modernize our architectures. Take elements from microservices, don't run from one extreme to the opposite extreme and find your way into Domain Driven SOA Design, in which I strongly believe. We can and will do this right if we can for once stop thinking so black-and-white.
Apart from that, SOA Suite on-premise and Oracle SOA Cloud Service are exactly the same from a developer's point of view. They are the same products, requiring the same type of code, being developed in the same JDeveloper. And while ICS is very good for integrating SaaS applications with each other, it's not going to be the cornerstone of anyone's enterprise architecture anytime soon. Therefore, SOA will remain relevant for a long time and when you know SOA, you can easily learn about ICS as well. The other way around will be significantly harder!
So, I'd like to conclude by turning mr. Vesterli's statement around: now is a great and exciting time to become an Oracle SOA developer.
dinsdag 10 januari 2017
How to use MDS Events in your BPM processes?
- Copy the event definition that you want to use into your project;
- Let your BPM process use the local event on design time;
- Open your composite.xml in source mode and change the import location of the event definition to the oramds: location;
- Remove the local copy;
- Deploy & enjoy!
maandag 9 januari 2017
How to handle your Canonical Data Model (CDM) in a SOA environment?
Problems occuring with a poorly setup CDM
1. One CDM to rule them all
2. Versioned CDM
3. Design Time CDM
Solution: domain driven CDM
General design consideration
woensdag 4 januari 2017
If you’re into integration, SOA or web services, you’ve probably heard the term Microservices fairly often lately. Is applying Microservices architecture the one-size-fits-all solution that can replace the traditional one-size-fits-all SOA solution that doesn’t fit anymore? Of course not, because the world isn’t just black and white and both architectural concepts have their pros and cons. However, I think we can learn from the Microservices movement to improve and modernize our traditional SOA systems.
Microservices vs traditional SOA?
As tradition dictates, you can’t write an article about Microservices without explaining what Microservices are. So here’s a link to Wikipedia and a picture: https://en.wikipedia.org/wiki/Microservices
So, now we have a clear understanding about Microservices, let’s also have a clear understanding about what I call “traditional SOA”. Traditional SOA, according to me, is a monolithic, semi-loosely coupled way of doing web services, where all services are deployed on a single platform (e.g. WebLogic Server), where services have a lot of dependencies, where scaling is an all-or-nothing effort and where most of the services are both stateful and synchronous. Typically, a canonical data model is used and services are sharing data stores. Obviously, there is much more to it, but you don’t need me to repeat whatever Thomas Erl and countless of other authors have already written.
Flexibility vs Reusability
Quite often, I sense the vibe that traditional SOA is old and irrelevant, while Microservices architecture is the only way forward. This is nonsense. In the end, what it comes down to is that traditional SOA relies heavily on reusability, while Microservices architecture relies heavily on flexibility. So, the main question in your reference architecture should be how much flexibility you need and how much reusability you want to give up on it. If you’re working on a disruptive new system that needs to adapt to changes rapidly, you have a different use case from traditional ERP or CRM integrations, where changes only occur occassionally and sudden scaling demands are not likely to happen. So, before you go and embrace Microservices, think about what kind of business you’re actually in and even if you have a need for Microservices, you probably won’t need them for all your integration efforts. I also strongly recommend using common sense in this matter, because dogmatic belief never leads to anything good. Basically, ask yourself what kind of system your service is for: a system of stability or a system of innovation?
What can traditional SOA learn from Microservices?
Let’s just say that you are not Netflix or Union Pacific and a traditional SOA approach prevails for your needs. Then you should still occasionally re-evaluate your SOA standards. Ideas that may have been great in 2011 might just have reached their expiry date, while new innovations can be analyzed to improve your architecture. I think that the traditional SOA approach can learn from the Microservices movement, because it gives a fresh perspective on things and makes us re-evaluate things we’ve been taking for granted. Even if your SOA implementation is successful and you hardly encounter any problems, establishing that you’re still on the right path can be useful! I’ve been doing SOA for a long time now and in many different projects I’m finding the same problems. How can we learn from Microservices to handle those problems?
Challenge #1: Scaling
Since everything is deployed on the same platform, scaling whatever needs more horsepower means scaling everything. With multitenancy in WebLogic Server 12.2.1, it’s possible to create domain partitions to overcome such problems. Try splitting up your SOA layer into different domains of services that scale together, possibly do the same with the underlying database, add work managers to those domains and you are already winning a lot. For example, I am currently involved in a project that deals with courthouse cases. Some cases are short running and happen often, while others are more rare, but longer running. Putting these into different domains will give you the flexibility to treat them differently, although dealing with underlying reusable services can still be a challenge. Those services could also be in their own domain though, but you could also go as far as deploying them to multiple domains or even having two different versions of such a service. Once again, it depends on the balance between flexibility and reusability.
Challenge #2: Performance
“Our services don’t perform!" is something that I hear too often. Obviously, here you need to look at the platform too: what’s the purging strategy, are we applying patches, is the configuration right? Tons of improvements can be made on that side, but pointing and blaming is no longer cool in the DevOps world, so we also need to look into the mirror: are we doing what we can to make our services perform well? Here we can apply some Microservices patterns: for example, if you are integrating between SaaS applications or between BPM processes and a relational database, do you really need stateful services in between? Think about the minimum of metadata that you need for each service and act on it: maybe use Service Bus instead of a Mediator, look at the use of each component in the service layering and get rid of redundant capturing of state. It will make your services run much faster. Try to be as stateless as you can be without getting into trouble.
Challenge #3: Dependencies
Dependencies are real killers of success. While Microservices are fully responsible for their own well-being, traditional SOA services tend to aggregate, orchestrate and use shared resouces. Aggregation is inevitable, but for orchestration there are some nice alternatives. For example, I’ve worked at a project where we had two BPM layers: one for end-to-end business processes that do orchestration and one for domain-bounded processes that do the actual processing. Instead of letting the top layer do orchestration through web services, you could also make it more loosely coupled through JMS or Events, so the entire building doesn’t collapse when one floors burn downs. At least consider it.
Another major dependency is the canonical data model. Having a general CDM that affects all services can be extremely inflexible and leads to unclear service definitions. I prefer a domain driven CDM approach (also see Challenge #1): make a CDM for each logical domain and have internal reuse of the objects (same namespace), while between domains there can be differences. For example, I have an Employment domain and a Person domain: in this case, a change in Person without relevance for the Employment domain will have no impact. This has the downside of needing some transformations, but at least you have a reasonable balance between flexibility and reusability. Personally, I don’t believe in taking such an approach for each individual service (hello Microservices), because you probably still want to be able to push through non-breaking changes quickly. Find your own balance in this, but try to avoid extreme measures.
Challenge #4: Purpose
With a Microservice, you always know exactly what it does, because it does exactly one thing. In SOA, we should also embrace such an approach, at least partially. Always try to make a service about exactly one object and make seperate services for “get" and transactional operations for the sake of scaling. Logically, aggregations can’t always be avoided, but then the aggregation itself should be considered one object. Also try to not make too many variations of basically the same operation: if needed, use a specific, non-reusable connector service for applications who need specific sorting, filtering etc…
Many organizations are struggling with their SOA approach, while not having a clear use case for rebuilding everything in a Microservices architecture. I believe that reading into the subject helps to understand the challenges that come with traditional SOA and I hope that this blog can help you address those challenges, as well as trigger you to put your design patterns under scrutiny on occasion. By gathering inspiration from different architectural approaches, we can already make a difference without fully adopting those approaches.