In our organization we have to implement different Business Process Flows for the different sales people on the Opportunity. I have created the different Business Processes. I am aware that I can switch the Business Processes on the form.
My question then: is it possible to set a different default Business Process for different users? For example: some sales people specialize mostly in quoting customers for training while other sell products. Hence there is a different Business Process for Goods than for Services.
Yes it is possible. It works similar as with forms, you can assign Business Process Flow to appropriate roles. See MSDN (here) for little bit more details.
Here you can find description with visualization.
Related
I'm preparing for the finals. I'm wondering what architecture I should use if I was told the following:
only one actor(librarian) is involved in the interaction with the system and he is responsible to initiate all the use cases of the system. System also does not store the information about Library staff and single user, the librarian is supposed to manage members and books in the system.
The choices are layered/Client-server/both. Someone told me that if there is only one actor then we do not use the client server architecture; but I'm confused if that was the case, why that's the case?
Also, what does the system not saving information have to do with this?
I don't thing having a single actor has anything to do with the system architecture in terms of layered or client/server.
the librarian uses the system to manage library members and books, so lets assume there are use cases to add a new book to the library, loan a book, add a new member, view lists of books and members, search, etc.
the librarian surely uses some client (doesn't matter if it's a web app or desktop app) that communicates with a server to get data for the librarian, and send his commands back to the server.
the server works with some DB (mySql, local files, mongoDB, whatever) to store the data.
I would assume for this kind of app to use n-tiers architecture. any app the has some client, some business logic, and data is probably 3-tiers at least.
the client renders data for the user, and submits his commands to the business logic tier. the business logic validates, processes, and writes/reads data from the data layer, which in turn communicates with a data store.
seems like you have at least a simple N-tier (or layered) application here. see here for a short and clear description of this subject.
regarding the "what does the system not saving information have to do with this?", I think it relates to "System also does not store the information about Library staff and single user" - meaning library staff management is not in the scope of the app, only books & members management.
As part of our journey towards API-led Connectivity, we have to group our resources (i.e. API endpoints) into multiple Mule applications for the experience APIs.
In order to have meaningful names for the Mule applications while maintaining the maximum re-usability, rather than associating the consumer names with the application names (which makes the experience API tightly coupled with the current application landscape), we propose to have Mule application names to reflect the essence of the business.
The list of the options are as follows. Which one do you think is more ideal? What approach have you used in your organization?
based on Channel/Consumer
A dedicated experience API for a consumer such as WEB, CRM, Mobile etc.
uri examples:
www.example.com/example-**web**-application/v1/
www.example.com/example-**crm**-application/v1/
www.example.com/example-**mobile**-application/v1/
Pro's: - applying channel specific policies is easier, management becomes easier, smaller outage window
Con's: - reusability reduces and chances of duplication of objects across api's increases
based on Business Domain
Company data model is used. Eg - Customer, Product, Payment etc.
uri examples:
www.example.com/example-**customers**-application/v1/
www.example.com/example-**products**-application/v1/
www.example.com/example-**payments**-application/v1/
Pro's: - promotes reusability, channel agnostic, same api can be used across different consumers.
Con's: management might get complex, larger outage window, multiple consumers might be impacted
based on Customer Journey
This approach is tied to the customer's lifecycle with the organization. Eg - Prospective Customer --> Lead --> Engage --> Payments --> Customer Retain
uri examples:
www.example.com/example-**prospect**-application/v1/
www.example.com/example-**lead**-application/v1/
www.example.com/example-**engage**-application/v1/
Pro's: channel agnostic, same api can be used across different consumers.
Con's: can get increasingly big and further breakdown might still be required
Thanks.
As far I understand your question; you would like to know what URIs to be using for the endpoints of the experience APIs, right?
Based on a recent blog entry from mulesoft (July 12 2017).
Experience APIs are:
Experience APIs are the means by which data can be
reconfigured so that it is most easily consumed by its intended
audience, all from a common data source, rather than setting up
separate point-to-point integrations for each channel. An Experience
API is usually created with API-first design principles where the API
is designed for the specific user experience in mind.
Based on the examples from MuleSoft and my understanding, the experience APIs are created for one given "experience"; web, virtual reality, mobile, etc...
You are trying to create an API for a given special experience to make the consumption of the API easy for this specific client.
According to my understanding the main goal on this level is not the re-usability. You focus on re-usability on the System API and Process API level, but the Experience APIs are supposed to make the life of the developers of the different clients easier by providing exactly the interface and data they need so they don't have to communicate directly with the system and process APIs, but they get a tailor-made API, suiting exactly their special needs.
Since the experience API is tailor-made for the special experience / channel / client-application; I think respresenting this in the URI is a good idea.
Just need to get something clear.
A GUI for employees managing a large scale of data, like facebook-users or whatever. Is that a form of CRM, or is CRM only business-facing?
In that case, what is that software category named?
CRM is a concept that describes Customer Relationship Management. So it can be used to describe any process that tracks an interaction with a person. Most typically between a company and a customer.
A classic example is that of a bank. You ring the bank on Monday and ask about a loan. They send you information in the post. You ring the bank on Friday. They should know that they spoke to you on Monday about loans and sent you a letter.
This may or may not use some software, although its unlikely they could just be writing everything down.
Wiki has quite a nice description:
Customer relationship management (CRM) is an approach to managing a company’s interaction with current and future customers. It often involves using technology to organize, automate, and synchronize sales, marketing, customer service, and technical support.
So that's the concept, in terms of the implementation there are a number of solutions and products which have varying architectures and are presented in different ways to both the company and customer.
For example;
Microsoft CRM, has a web page but typically this is only accessible
by business users. The customers interact with the company, and the
company interacts with Microsoft CRM.
However the lines can get a little blurred, for example its not unusual for companies to build self-service portals which integrate into Microsoft CRM. In this way customers are directly interacting with Microsoft CRM.
In terms of your points:
A GUI for employees managing a large scale of data, like facebook-users or whatever. Is that a form of CRM
I would say yes. However it could also cross into sentiment analysis, and data mining.
is CRM only business-facing?
As described above, CRM is a concept. Its implementation is often business facing only, but not always.
I am working on a project that designed base on Domain Driven Design.
In this project, we have 5 layers:
Infrastructure
Domain
Application Service
Distributed Service
Presentation
I am confused about how to put my business logic among Infrastructure, Domain and Service layers. Sometimes I put the business logic condition in iqueryable Linq in a repository; sometimes I load all the objects to memory and put them into services; and sometimes I put them in the method of an object. I don't know which way is the right way. Which layer should be responsible for this business logic?
I need some concrete reasons to convince a team of developers that business logic in code is better, because it's more maintainable. I used to have a lot of business logic in the DB, because I believed it was the single point of access.
Stored procedure are usefull to speedup certain DB operations.
Stored procedure are evil because:
it's hard to versioning (not the hardest thing, but harder than versioning your project)
it's harder to deploy (e.g. in my job we have thousand of DBs with thousand of stored procedure's on a couple of servers; when we change logic of a SP we have to update every DB: a pain in the neck.)
it's difficult to debug,
it's difficult to unit test
Said that... implementation of repositories are infrastracture, and infrastracture doesn't know about domain and business logic.
After all I can't really see DDD in this question, maybe you should deepen concepts like entity, value object and aggregate root, together with repository and domain model.
The only thing that we can confirm right now is: Business logic intended as domain logic belongs to the domain model/domain layer. The domain logic is rules that act always in the same way apart from the use case (e.g.: if the order is more expensive than 100$ the shipment is free).
If you have a rule that depends on a use case (e.g.: if a user browse my e-commerce with the appmobile than ...) this is application logic.
DDD also follows the "seperation of concerns" rule so business around domain stays in domain layer and if something outside of domain is dependent then we put them in higher layers like model views in presentation layer.
I know this is old, but I've had some experience working on older projects where the database held all the logic and various systems used that logic. Updating any of those systems became a nightmare of making a change to any of it would break something somewhere else.
DDD was built to get around these exact scenarios.
Think of it as you having one focused application that controls it's domain, defining the domain is often hard, but lets say you could define a traditional system with 3 domains.
Commerce Domain controls how to take orders.
Logistics Domain controls how to ship orders.
Billing Domain for how orders are paid for.
Each one of these domains would ideally be represented layered applications, but the whole end to end story of an "order" involves all 3 applications. Each domain controls it's business and is responsible for doing it's job the best way it can.
Billing Domain could be as simple as a web api that appends order data to a csv file that someone in accounting opens once a month and hand types an invoice out. Or it could grow into a massive complex beast of quickbooks integrations automatically pulling money from saved accounts. The Commerce and Logistics domain shouldn't have to care about where the billing domain is saving it's data or how they're getting paid. They just have the responsibility to inform the billing domain when something is sold and when something is shipped.
The Commerce domain likewise shouldn't have to care about how shipping costs are calculated, it just needs to ask the Logistics domain. Commerce shouldn't be rooting around in a database that Logistics needs, becasuse then if Logistics wants to pivot and use google maps to determine shipping costs we'll need to update Commerce then as well.
Once you understand the concept of "Every domain controls it's data, if you need that domains data, you ask that domain." The next bits kinda fall in line.
Each domain will have a Presentation Layer or two, this can be a website, api, mobile/desktop app or a combination of the above. Each domain will have business logic in a domain/application layer. Each domain will be supported by infrastructure like databases and apis.
In the above example we could have a Commerce Domain. It's presentation layer renders a website to a user, it's domain layer is composed of OrderPage and interfaces for commands/queries. It's infrastructure layer has logic to handle those commands and queries, most of them probably go to a private database, but we also have some api calls out to the Logistics and Billing domains.
Our Billing Domain has 2 projects in it's presentation layer. One is an API that's used to field requests from the Commerce and Logistics domains, the other is a desktop app that we wrote for accounting. They both talk to the same domain objects/interfaces so if accounting needs to log in and manually modify an order, they can do so just as easily as if it was happening on the website. The interfaces in the domain are implemented by the infrastructure which could be a quickbooks api which will also forward data into freshbooks until that big migration is finished. No code in Commerce and Logistics has to care about freshbooks/quickbooks, and we can use both at the same time if we want to.
Our Logicstics domain similarly has two projects in it's presentation layer. A console app that runs on a scheduled task once a morning to batch up orders and an api. Same deal with it's data.
Ok that got a bit too long and I'm going to wrap that up. No one will probably read this answer on a 4 year old post anyways lol.
I use Skyscanner a lot myself, and one thing I don't like is the fact that I get redirected when I want to book. I want to know what the obstacles are in having a solution where you can book your flights without being redirected and without necessarily being a reseller/travel agent.
The objective is to make comparison shopping seamless.
I understand low-budget carriers prefer booking only on their site, but perhaps their strategy can be integrated within the comparison site.
I also understand that carriers would want customer analytics, but this can be made fully available to them.
What are the reasons for example KLM, Airfrance etc might NOT want to make comparison shopping seamless?
I have been a main developer for one of such website which uses such APIs. I would list many reasons but also it is a good practice not to do so.
Just some reasons off the top of my head.
1) It is not the purpose of such websites. They just join an affiliate program to redirect users and get some small fees for purchases. They would keep their system as simple as possible.
2) Airline and other provider like hotels have their own policy on fees, refund, purchase, loyalty points etc. As a third party, you can not implement such a thing for each provider. If you dont implement, then you would use API, right? They wouldn't expose such inner workings of their system to third parties, payment involves PCI compliance, customer confidentiality etc.
3) Such services involve certain confidentiality and privacy. Somebody's passport, staying at a particular hotel or flying on a particular plane is sensitive information and should not be available to third parties.
Just imagine how many third parties their API are available. No trusted company would allow this to happen.
4) Even if they allow, no third party can really ensure security of such sensitive information. If a breach of security happens, thousands of airline data etc. would be affected.
5) Each of airline and hotels might be subject to different jurisdictions in terms of data protection etc. It is technically impossible to combine them.
many many other reasons..... There are also many issues in handling payment, accounting etc.