This document is for developers who integrate Oracle Monetization Cloud with external applications, for example, with a customer management system.
Each type of data in the database has its own type of object. For example, accounts are stored in /account objects, and events are stored in /event objects.
The formatting convention for object names is /object_type, such as /service. API descriptions and sample web services operation code reference objects using this convention. For example:
<POID>0.0.0.1 /account 297583 8</POID>
Some objects have sub-types. For example, /service objects can have many sub-types, such as /service/email and /service/broadband.
Note:Object types and their sub-types are often referred to as classes and sub-classes in the API descriptions.
You can create your own service types in Oracle Monetization Cloud. When you do, the data for the service is stored in a sub-class of the /service class.
You can also create your own events in Oracle Monetization Cloud. For example, to charge customers for a movie download, you could create an event named /event/movie_download that stores data about every movie that a customer downloads. You could then write an application to find all of the movies that a customer downloaded by searching for the /event/movie_download objects associated with the customer's account.
Every object stores data in fields. For example, when you create an account, the /account object includes fields for the customer's name, address, and so on. You can view fields in objects from the data returned by API operations. For example, you can view some fields in the /account object from the data returned by the pcmOpCustCommitCustomer operation, which creates the /account object:
<INV_INFO elem="0"> <ADDRESS>123 Hollywood Boulevard</ADDRESS> <CITY>Los Angeles</CITY> <COUNTRY>USA</COUNTRY> <DELIVERY_DESCR>test_001</DELIVERY_DESCR> <DELIVERY_PREFER>0</DELIVERY_PREFER> <EMAIL_ADDR /> <INV_TERMS>0</INV_TERMS> <NAME>Chet3457 Chet8905</NAME> <STATE>NJ</STATE> <ZIP>90001</ZIP> </INV_INFO>
Every object in the database has a unique identifier called a POID. You use the POID to specify an object in calls to web service operations. For example, to read the contents of a package in the database, you use this operation:
<bus:pcmOpReadObjRequest> <bus:PCM_OP_READ_OBJ_Request> <bus:flags>0</bus:flags> <bus:PCM_OP_READ_OBJ_inputFlist> <bus:POID>0.0.0.1 /plan 298723 8</bus:POID> </bus:PCM_OP_READ_OBJ_inputFlist> </bus:PCM_OP_READ_OBJ_Request> </bus:pcmOpReadObj>
In addition to identifying objects, POIDs link objects together. For example, in this figure:
The /bill and /invoice objects point to their related account by specifying the POID of the /account object.
The /bill object points to the /invoice object, and the /invoice object points to the /bill object.
You can use these links between objects when you use web services operations. For example, to change the status of a service, you use the pcmOpSubscriptionSetProductStatus operation. In that operation, you use this XML to identify the account that owns the offer, the service associated with the offer, and the offer whose status you'll change:
<bus:PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS_inputFlist> <bus:DESCR>Due to activating/inactivating an account/service.</bus:DESCR> <bus:POID>0.0.0.1 /account 297583 0</bus:POID> <bus:PROGRAM_NAME>web service</bus:PROGRAM_NAME> <bus:SERVICE_OBJ>0.0.0.1 /service/email 298223 0</bus:SERVICE_OBJ> <bus:STATUSES elem="1"> <bus:OFFERING_OBJ>0.0.0.1 /purchased_product 294943 1</bus:OFFERING_OBJ> <bus:STATUS>2</bus:STATUS> <bus:STATUS_FLAGS>0</bus:STATUS_FLAGS> </bus:STATUSES> </bus:PCM_OP_SUBSCRIPTION_SET_PRODUCT_STATUS_inputFlist>