uneasy, sending CAN messages seems trivial at first, but it isn't. First, you must distinguish between the CAN frame and OBD-II messages. CAN is only the transport of the message, where OBD-II is a protocoll which describes what is carried inside the data.
You can't just send a single frame containing OBD-II information an expect a replay, it's not simple challenge/response. You must first establish a session.
Your car uses a foreign protocoll and codes the messages according to it's own standard. You can, of course determine current RPM from a OBD-II CAN communication, but also direct from the appropriate CAN-Message the powertrain module is sending to other modules in the car, e.g. the instrument-cluster which displays the RPM value by a gauge.
Also there are at least two separated CAN-busses in your car. One for the powertrain and one for comfortsystems (central locking, doors, interior light, etc.). Some cars so have an additional bus for multimedia/audio systems. Not all information is available on every bus. The powertrain is mostly driven at 500 kbit/s whereas the comfort and multimedia is 250 or 125 kbit/s. Often a gateway routes messages from one bus to the other. The OBD-II port of your car is a good place to gain access to the CAN bus(ses). At least HS-CAN (powertrain) and MS-CAN (comfort) are connected here. If you are lucky, they are directly wired to the bus. But some vendors connect the OBD-II port to a special gateway device, which will filter all traffic not wanted or authenticated to the car. This device is most often the router between the busses.
So, without some deeper knowledge of your cars wiring and modules, there are too many pitfalls. You should try to get some wiring diagrams and bus-lists. I done this myself before and believe me to start this way, or will won't get happy. Take a look here, on my website, where you can find the results of my research on Ford Mondeo MK4: UMGELEITET [MK4-Wiki]
I've spend hours and hours loggind CAN data, parsing, filtering and reading logs to know what CAN-ID came from which module, takes what data and how it is assembled. There are hundrets of messages with thousands of different data. To analyze them and find actors, sensors i "invented" some processes. The simplest is to look for differences in data while pushing some button. You can filter out all data not changing while you push a button on your dash and focus on the remaining. Then build a time profile to synchronize a data change with your action. This can mostly be done by looking at CANhacker in Monitor-Mode.
Push buttons are flags/bits and very easy to find. Komplex values hide better 
Sometimes you need to know how the data is coded, even if you are shure about where in the messages it is. E.G. decimal values often shiftet by the number of their fractional part. So a 28.3 degree value could be in a two byte data, coded as 283. Also values which can have a sign (+ or -) can be coded with an offset. Temperaturevalues for example, often added with 40, so a value of 0 means -40° and a value of 40 means 0° and 60 means +20°.
You must know to divide by 10 to get the value in question. Other values are more complex to calculate, not all are linear. This is the hardest part. Look at OBD-II content. Here you find math to calculate the values. Maybe they are used by the car manufacturers CAN-messages also...
,