I have a very basic requirement for a CRM I'm building in the Consumer Debt space. An issuer, say Bank of America, has to charge off a credit card, so then send the credit card with the information to the collections department which can either farm it out to a collection agency, or sell the charged-off debt to another debt buying company. While they're trying to collect the debt, they'll log bits of information about the customer: last address, are they working, did a collection company get involved. That is, they'll collect information about the consumer behind the credit card.
Usually, the debt is passed on to a debt buyer who goes through this whole process again, usually with almost no information from BofA about the previous attempt to collect.
So here's the question: is there any capability in Microsoft CRM (or Salesforce) that would allow this customer record to be sold/transferred/shared between tenants? The idea is that the consumer would be much better represented if their information flowed with the credit card as it made it's way through the debt buyers and collection agencies.
Salesforce has a feature called Salesforce-to-Salesforce that does allow the sharing of data between two previously linked orgs.
You could also build your Managed Package that included web services/callouts to do this.
Dynamics 365 (formerly CRM) can import and export data effortlessly to/from Excel files.
I don't have a clue about Salesforce, but it's reasonable to believe it can too.
To make the data interchange seamless between parties, there would have to be an industry standard way to describe a consumer credit collection profile.
For example, the finance industry has the FIX and FIXML protocols to describe trading transactions, and the publishing industry has the ONIX format for book metadata.
There appears to be something called the Metro 2 format in the credit industry, but I'm not sure if it includes collections information.
If a standard format existed, ISV's could write add-ons for Dynamics 365 and SalesForce to import and export standardized profiles.
Related
How multiple teams(which own different system components/micro-services) in a big tech company share their databases.
I can think of multiple use cases where this would be required. For example in an e-commerce firm, same product will be shared among multiple teams like product at first will be part of product onboarding service, then may be catalog service (which stores all products and categories), then search service, cart service, order placing service, recommendation service, cancellation & return service and so on.
If they don't share any db then
Do they all have redundant copy of the products with same product ID and
Wouldn't there be a challenge to achieve consistency among multiple team.
There are multiple related doubt I have in both the case wether they share DB or not.
I have been through multiple tech blogs and video on software design, and still didn't get satisfying answer. Do share some resources which can give a complete workflow of how things work end-to-end in a big tech firm.
Thank you
In the microservice architecture, each microservice exposes endpoints where other microservice can access shared information between the services. So one service would store as minimal information of a record that is managed by another microservice.
For example if a user service would like to fetch orders for a particular user in an e-commerce case, then the order service would expose an endpoint given a user id would return all orders related to the userid supplied and so on...so essentally the only field related to the user that the order service needs to store is the userid, the rest of the user details is irrelevant to it.
To further improve the cohesion and understanding between teams, data discovery apis/documentation are also built to share metadata of databases to other teams to further explain what each table/field means for one to efficiently plan out a microservice. You can read more about how such companies build data discovery tools
here
If I understand you correctly, you are unsure how different departments receive data in a company?
The idea is that you create reusable and effective API's to solve this problem.
Let's generically say the company we're looking at is walmart. Walmart has millions of items in a database(s). Each item has a unique ID etc etc.
If Walmart is selling items online via walmart.com, they have to have a way to get those items, so they create API's and use them to grab items based on certain query conditions.
Now, let's say walmart has decided to build an app... well they need those exact same items! Well, good thing we already created those API's, we will use the exact same ones to grab the data.
Now, how does Walmart manage which items are available at which store, and at what price? They would usually link this meta data through additional database schema tables and tying them all together with primary and foreign keys.
^^ This essentially allows walmart to grab ONLY the item out of their CORE database that only has details that are necessary to the item (e.g. name, size, color, SKU, details, etc), and link it to another database that is say, YOUR local walmart that contains information relevant to only your walmart location in regard to that item (e.g. price, stock, aisle number etc).
So using multiple databases yes, in a sense.
Perhaps this may drive you down some more roads: https://learnsql.com/blog/why-use-primary-key-foreign-key/
https://towardsdatascience.com/designing-a-relational-database-and-creating-an-entity-relationship-diagram-89c1c19320b2
There's a substantial diversity of approaches used between and even within big tech companies, driven by different company/org cultures and different requirements around consistency and availability.
Any time you have an explicit "query another service/another DB" dependency, you have a coupling which tends to turn a problem in one service into a problem in both services (and this isn't a necessarily a one-way thing: it's quite possible for the querying service to encounter a problem which cascades into a problem in the queried service (this is especially possible when a cache becomes load-bearing, which has led to major outages at at least one FANMAG in the not-that-distant past)).
This has led some companies that could be fairly called big tech to eschew that approach in their service design, typically by having services publish events describing what has changed to a durable log (append-only storage). Other services subscribe to that log and use the events to construct their own eventually consistent view of the data owned by the other service (i.e. there's some level of data duplication, with services storing exactly the data they need to function).
Assuming a e commerce web app has a high amount of requests, how do I prevent two users from choosing the only product left? Should I check the quantity when adding to shopping list or payment? Is it using a field to record quantity of selected product in DB is bad way? How does the large e commerce web app like amazon deal with conflict problem?
Several options that I know :
For the RDBMS that support ACID , you can use optimistic locking technique on the product table. Unless it is very often that many users hit the buying button on the same product at the nearly same times ,it should work pretty well.(For how many users does the 'many' means, you have to measure it. I think 1k should be no problem. Just my guess , don't take it for granted)
Do not check it and let users to buy it. Adjust the business flow to handle it. For example, when an user hits the buying button ,tell him his order is just accepted and will be processed but not guarantee he must able to buy it. Then in the later stage when you find that there is not enough inventory to ship the product to him , send an email to apologise and refund to him.
Also in the real business , it is common that the product inventory can go to negative and still accepting orders but tell the user he will get the product at XXX days later. The business can then produce or order more product from the supplier after receiving the money.
If you are buying iPhone on the Apple web site , it also works like this.
It really depends upon the number of concurrent users here. In the case of millions, the NoSQL approach is prefered to manage the basket with eventual consistency then the buying process would go with ACID to ensure the product can be sold.
For less users, you can rely on an ACID database.
If you are not sure, you may go with a database that has ACID capabilities but can as well allow you to work in an eventual consistency way or that can implement the concept of sharding for scalability purpose. To my knowledge Oracle can do these 3 things: COMMIT NO WAIT, COMMIT and Sharding deployment.
HTH
As part of a personal research project, I'm attempting to learn more about Microservice architecture and how to incorporate it within the industry I work with.
I've been reading a lot of booked and articles around Microservice architecture, and have been researching and working with multiple different software components to support this architecture, such as RabbitMQ, however I have come unstuck at initiation of the data models.
To put the requirement in it's simplest form, lets say I have the requirement for two Microservices for the following high level requirement (please note, I am excluding the WebAPI / Bridge microservice and UI microservices as part of this process, I am just focusing on the backend Microservices that house core data):
Requirement:
Provide the ability for a customer to log into a portal and add register for a "scheme", which allows them to add money or credit to their record. This will be a multi-tenanted solution, where data can be placed in a single database or over multiple databases (already covered) and each Microservice will be responsible for it's own table(s).
Some "tenants" may or may not have the "Credit Microservice" enabled as defined below and may only have the "Customer Microservice" and potentially other Microservices such as "Marketing Microservice" (not defined below, but referenced as an example)
Customer Microservice:
Responsible for managing customer information within the system, such as First Name, Last name, email address, etc. This Microservice will expose various functions such as Creating a new Customer, Updating an Existing customer, Deleting a customer and finally retrieving customers (Basic CRUD operations).
This Microservice will be fed data directly from our internal CRM (Customer Relationship Management) system via integration (this part is covered)
Data Scheme:
CustomerId
FirstName
LastName
EmailAddress
Once a customer is created, an event is posted on the message queue informing other microservices that a Customer has been created.
Credit Microservice:
Responsible for managing a customers balance and scheme enrolled within. By default, a customer will NOT be enrolled in a scheme, and will therefore NOT be able to deposit credit to their account.
This Microservice will expose functions to "Enroll" a member to a scheme and "AddCredit" to their account as well as retrieving the information for a particular customer (their scheme and balance). In real life, this would also let them change scheme, and have various other options, but I'm keeping that out of this for this simple example.
Within the system, this Microservice would likely be responsible for storing the "transactions" to credit as well, in a separate table within it's database (or unique schema within a single database instance). This is not defined below as it is irrelevant to the issue at hand.
Data Scheme:
CustomerId
SchemeName
Balance
This Microservice will be responsible for listening to events from the Customer Microservice and creating new customers within it's own unique SQL table, allowing that customer to Enrol or Add Credit to their account.
Issue:
Within the UI element of the application, I need to show admin users a list of customers, including if they are enrolled in the application or not, as well as how much credit the customer has, but only if they have enabled the "Credit" functionality (the identification of this is already covered, each tenant can enable certain Microservices when setup)
The issue comes in the fact that the data is stored over two tables, and mastered by two different Microservices...
Do I create a new Microservice (EG: CustomerCredit) that joins the two tables together (readonly) to display the results? Does the API call the Customer Microservice "retrieve" first then call the Credit Microservice "retrieve" after with the relevant IDs and then join them together?
The first example above does not work in practice, as I might have MULTIPLE microservices extending the schema of the customer model, for example, Marketing where I might store "Last Email Date" against a customer id.
EDIT:
To confirm, the structure would look similar to the below:
I see that EBay has an affiliate API for sending customers to EBay:
http://developer.ebay.com/devzone/guides/ebayfeatures/Basics/eBay-AffiliateTrackingConcepts.html
However, is it possible to track conversions and see if a specific customer purchased a specific product? I can't find any data on getting affiliate reports or what the reports contain.
If you go to the eBay Partner Network and click on Reports > Download Reports you can generate reasonably detailed traffic and revenue reports, down to the ItemID.
With regards to determining which specific eBay username has lead to the conversion, I really don't think this is something that eBay would make publicly available to you.
As much as we would all like to know who it was it was that entered into a frantic bidding war at 23:06:11 to win that almost new Jenna Jameson Moulded Pussy and Anus, in many circles this is considered personal information.
The above notwithstanding, however, you could apply your own tracking methods through the use of advertising campaigns, which are trackable within the revenue reports. Batch campaigns can be made by clicking Campaigns > Create Campaigns in Bulk. From there, it would be a matter of disseminating links to each campaign and logging to whom each was advertised.
More information can be got from the User Manual
This is the scenario i have:
im developing a web app that will list down all the details of a car that the user picks from a list. I have a database of all car models, makes, sizes, prices etc. Besides i also have the price trend for the past 5 yrs. You may assume that i have a few of such tables and the data volume is about 10s of thousands of records.
My online application should be able to let the user pick his choice of one car model and optionally provide his address. With just this user input, i want to be able to generate a pdf report with the following information:
Comparison of selected car model with other cars manufactured in the same country. (e.g, if user selected, honda, i want to compare it with toyota, which comes from the same country)
Comparion of selected car with other car of similar type (eg. sedan vs sedan)
Price trend of the car for the last 5 yrs - Nearest car workshops in user's neighbourhood within a radius of 10km (if user has given me his address)
i will be drawing out several other data from my database.
I would like to present this report instantly, say within 3 minutes to the user. So now the question, is, what software/tools/program/database etc should i be using, taking in consideration the huge amount of data and the need to present this in the fastest possible time as a pdf report?
There are whole lot of possibilities. You can use PHP (or) Java (or) .Net (or) so on...for web application, MySQL, SQL Server, Oracle etc., as database (If data is really big and grows like anything daily you may consider Hbase also) It dependency on how soon you want your product out in the market and how much scalable it should be and how much comfortable you are with any of those technologies.
Some technologies support nice user interface, some may not but strong in other area of web application.
How much money/time you have for development, licensing also plays role in deciding answer for this question.