We have an ERP system made in java that we will adapt to 3-tier architecture, and we want to add transaction controls (JTA).
We read that the best way to analyze where to place the controls was to create a graph of the system scenarios using BPM and then adding controls to the graph.
the web give us 2 ways to make the graph:
By way of use (scenarios) of each module, adding to the graph the
different routes that can be done by using a module, for example: in
the invoice module the different ways to complete it (with detail,
without detail, etc...)
By relation between the modules, adding to the graph how passes from
module to module, for example in invoice how passes to client
account
Our question are:
Which is the best way?
Is there another way to do that?
Definitely, using a BPM solution like jBPM will help you to define your business scenarios and discover the interaction between the different departments and modules in your company. If you want to use BPM there will be some things to learn, I would suggest you to take a look at BPM solutions and see if that can help you in your specific implementation.
Related
I am new to opendaylight and I seek help regarding following:
How can I make two different applications communicate with each other?
Can I have something like a communication bus for my selected set of applications that can transfer data to each other? Or Do I need to have a single application with submodules (with different features ) to achieve the same task, i.e feature communication in this case.
The main feature that sets OpenDaylight (ODL) apart from other SDN controllers is the Model-Driven Service Abstraction Layer (MD-SAL), which provides a framework to share structured/modeled data and send notifications between ODL applications, among other things.
If you want to transfer data between ODL applications, you first need to model it using YANG, and include the YANG model in one of the applications.
To take advantage of the features offered by MD-SAL, please take a look at the official documentation. Once you understand the architecture, you should look at the source code of existing applications to see examples of how to take advantage of the power of MD-SAL.
I have recently been tasked to look into Workflow Foundation. The actual goal would be to implement a system in which the end users can define custom workflows in the deployed application (and of course, use them). Personally I have never used WF before (and reading around here on SO people are very doubtful about it - so am I reading those questions/answers), and I am having a hard time finding my way around it given the sparse learning resources available.
Anyway, there are some questions, for example, this, which mention something they call dynamic or user-defined workflows. They point out that WF makes it possible to "rehost" the designer, so that end-users can define their own new workflows after the application is deployed (without developer intervention (?), this is the part I am not really sure about).
I have been told by fellow employees that this way we could implement an application in which once this feature is implemented we would no longer have to keep modifying the application every time a new workflow is to be implemented. However, they also pointed out that they just "heard it", they don't have firsthand experience themselves either.
I have been looking around for samples online but the best thing I could find was a number guess app - barely more than a simple hello world. So not much that would point me to the right direction of how this user-defined workflow feature actually works and how it can be used, what its limitations are etc.
My primary concern is this: it is alright that one can define custom workflows but no workflow is worth a penny without the possibility of actually inputting data throughout the process. For example, even if the only thing I need to do is to register a customer in a complaint management system, I would need the customer's name, contact, etc. If the end user should be able to define any workflow the given toolset makes possible then of course there needs to be a way to provide the workflow consumers with a way of inputting data through forms. If the workflow can be of pretty much any nature then so needs to be the data - otherwise if we need to implement the UIs ourselves then this "end-user throws together a workflow" feature is kind of useless because they would still end up at us requiring to implement a form or some sort of data input for the individual steps.
So I guess that there should be a way of defining the "shape" of the data that needs to be filled at any given user interaction phase of the workflow which I can investigate and dynamically generate forms based on the data. So for example, if I found that the required data was made up of a name and a date of birth, then I would need to render a textbox and a datepicker on the page.
What I couldn't really figure out from the Q&As here and elsewhere is whether this is even possible. Can I define and then later "query" the structure of the data to be passed to the workflow at any point? If so, how? If not, how should this user-defined workflow feature even be used, what is it good for?
To clarify it a little, I could imagine something as specifying a complex type, which would be the view model (input model) in a regular MVC app, and then I could reflect over it, get the properties and render input fields based on that.
Windows Workflow Foundation is about machine workflows, not business workflows. True, it is the foundational tool set Microsoft created for building their business workflow products. But out of the box WWF does not have the components you need to quickly and easily build business workflows. If you want to send an email in a workflow, you have to write that from scratch. Just about anything you can think of doing from a business point of view you have to write from scratch.
If you want to easily create business workflows using Microsoft products check out the workflow stuff in SharePoint. It is the easiest of the Microsoft products to work with (in my experience.) If that does not meet your needs there are other products like BizTalk.
K2 is another company with a business workflow product that uses WWF as their base to more easily build business workflows, the older K2 products actually create web pages automatically to collect the data from the user.
WWF is very low level, arguably it lost traction after they re-wrote the whole thing in 4.0. While not publically stated by Microsoft, my personal opinion is Service Fabric (from Microsoft) achieves the goals WWF originally tried to solve which was a "more robust programming environment."
What is the relationship between an FDD and a DFD of the same system?
Functional decomposition is about partitioning the functionality of a big complicated system, into smaller, preferably simpler parts. The FDD is a tool that aids you in this process. Basically, you are breaking down of the capabilities of a complicated system, into a set of more specific logically grouped capabilities.
Now, a data flow diagram deals with how data flows through a system for a specific function of the system. So, each of the above mentioned capabilities might very well have their own unique data flows.
For example, if you have an FDD diagram describing a blogging system. You might have functions for say, displaying a blog post, editing a blog post and potentially sending a link to a blog post to a friend.
These three functions will all have fairly different data flows, which can be modelled separately with DFDs. So, I'd say the relationship between these two types of diagrams are that one can help identify the individual functions, which might, or might not, need to have an associated dataflow mapped.
Hope that is helpful.
I have to integrate various legacy applications with some newly introduced parts that are silos of information and have been built at different times with varying architectures. At times these applications may need to get data from other system if it exists and display it to the user within their own screens based on the business needs.
I was looking to see if its possible to implement a generic federation engine that kind of abstracts the aggregation of the data from various other OData endpoints and have a single version of truth.
An simplistic example could be as below.
I am not really looking to do an ETL here as that may introduce some data related side effects in terms of staleness etc.
Can some one share some ideas as to how this can be achieved or point me to any article on the net that shows such a concept.
Regards
Kiran
Officially, the answer is to use either the reflection provider or a custom provider.
Support for multiple data sources (odata)
Allow me to expose entities from multiple sources
To decide between the two approaches, take a look at this article.
If you decide that you need to build a custom provider, the referenced article also contains links to a series of other articles that will help you through the learning process.
Your project seems non-trivial, so in addition I recommend looking at other resources like the WCF Data Services Toolkit to help you along.
By the way, from an architecture standpoint, I believe your idea is sound. Yes, you may have some domain logic behind OData endpoints, but I've always believed this logic should be thin as OData is primarily used as part of data access layers, much like SQL (as opposed to service layers which encapsulate more behavior in the traditional sense). Even if that thin logic requires your aggregator to get a little smart, it's likely that you'll always be able to get away with it using a custom provider.
That being said, if the aggregator itself encapsulates a lot of behavior (as opposed to simply aggregating and re-exposing raw data), you should consider using another protocol that is less data-oriented (but keep using the OData backends in that service). Since domain logic is normally heavily specific, there's very rarely a one-size-fits-all type of protocol, so you'd naturally have to design it yourself.
However, if the aggregated data is exposed mostly as-is or with essentially structural changes (little to no behavior besides assembling the raw data), I think using OData again for that central component is very appropriate.
Obviously, and as you can see in the comments to your question, not everybody would agree with all of this -- so as always, take it with a grain of salt.
I'm building a rails application and I'm having trouble working out how create diagrams for the application architecture.
I've created UML class diagrams in the past, so consequently that's where I headed. I've found the railroady gem that generates UML class diagrams via a rake task, however it separates the models from the controllers - which feels fragmented to me.
What I want to know is whether there is another (preferably better) way to model an MVC (rails) web application.
I'm not necessarily looking for a gem to generate the diagram for me, I'm happy to create it manually in visio, I just don't know what type of diagram I should be using.
You may want to try the Robustness diagram, also sometimes called MVC diagram.
See for example here and there.
It is not really a UML diagram, but most UML tools manage it through stereotypes and custom icons. The tool I use, Magicdraw UML, uses a class diagram, but I think I heard of tools that use communication diagrams (not sure, though).
However, it may or may not meet your expectations, as it is a very global diagram.
There exist a metodology named UWA (Ubiquitous Web Application) that allows you to describe not only the data structure, but also the navigation, presentation and transaction models.
The UWA methodology has a user-centered approach, which improves the requirement and design definitions. Since this metodology was developed specifically for modelling web applications, it allows a clear separation of content, navigation, transaction, publishing and operational elements.
UWA begins with a goal-oriented requirements engineering that naturally arise to later design stages, revealing key features that should be implemented. This leads to reasoning about some requirements that might have not been identified beforehand, or may have been underrated.
You may find additional information about UWA here.
Even if you decide not to apply this methodology, it may provide you with some tips about adapting UML diagrams to web applications.
Have you ever come across a Use Case Diagram before? It's not strictly a diagram to outline a systems architecture, but it does provide a good visual representation of communication with other parts of the system/ external actors, during a given "use case" (or process).
For example:
User(Actor) --> Update Status(Use Case)--includes-->(Log in)
Here we have a user wanting to update their status. In order to do this, they need to be logged into the site (an included use case). Thinking about this in MVC mode, we know that "Update Status" and "Log in" would both be controller methods, which would both communicate with the attracted website database (also an actor), thus demonstrating the communication path within a system.
Actors of a system can be anything that communicates with the actual system during a process, usually externally, so users, browsers, database, clients etc.
In terms of modelling the MVC architecture, this is done best by the Class diagram, but a Use Case diagram would also aid in the visual representation.
I always draw up a Use Case and Class Diagram together before I start coding, as a way of extracting the system requirements and laying them out in a working design. UML diagrams are design tools after all- there's not really much point in creating one after you've written the system code!
Just something to think about anyway- hope this helps!
brief overview of basic use-case diagrams