- Why are there an id and an external_id for some resources?
id is the identifier generated by the system which receives the POST request. External_id is the identifier used by the system which is sending the POST request. The objective is to have for some resources both Orange and partner ids. To know which are the id filled in the request and the response, see getting advanced document inserted inside getting started, it will clarify if what are the ids filled by Orange when sending POST request and the ids to fill by partner in the answer.
- What is productRefId inside productOrdering and userService APIs?
productRefId is the identifier of the licenses fleet. productRefId is generated by partner when returning the answer of new licences to create (answer of productOrdering API) . For all next orders (new licences to create for an existing customer) or to consult licenses of one customer, Orange will send this id to the partner. When partner receives new licences to create with this productRefId, partner is free to decide to integrate the new licences inside the fleet with this identifier or to generate a new fleet with new productRefId to integrate these new licences. In all cases, the productRefId used to integrate new licences is sent back in the answer of productRefId. As productRefId, partner has choice between using customerId, generate a dedicated id for each order of new licences, generate only one id for customer's fleet and use it for all orders of new licences, generate one id per subscribed offer for one customer and use it each time there is an ordering of licences for this offer . Whatever the choice of partner, Orange will use this productRefId to consult the whole fleet of one customer. If several productRefId were generated for one customer, Orange will do several requests to build the whole fleet of the customer.
- What happens in the requests and answers for data with no value?
Data with no value are not sent at all, the field will not appear inside the body. Consequently the mapping should not be done in a strict way. The "getting advanced' document inserted inside getting started precizes clearly which are the data provided or not in the request and answer of API calls.
- Synchronous and asynchronous answer, how does it work?
If the answer provided by partner is not synchronous, the status of the synchrounous call back is "acknowledged". It means that the synchrounous answer does not contain business values, it is only a technical answer to indicate that the call well happened. In this case, the business answer is provided by partner calling the "event" resource provided inside productOrdering and userService APIs. Inside "event" there is productOrder and userService resources to provide the business answer when the business process to manage the request was ended.
If the answer provided by partner is synchronous, then the "event" call is not implemented by partner. The business answer is directly provided inside the answer of productOrder and userService calls. "Acknowledged" status is never used in this case.
- productOrdering has 2 roles, managing customer and managing orders isn't it?
Yes, productOrdering is used both to manage customer (creation of customer and deletion of customer) andproductOrdering is also used to manage orders of one customer(initial order, adding of new licences inside customer's fleet). Depending on the goal of the call, provided data are different. The document "getting advanced" inserted inside getting started provides all details about provided data depending on the goal of the API call.
- What is the role of realizing resource and link with end user information?
Realizing resourceis the technical support of licences of partner's service. Depending on the partner's service, it could be a specific value per delivered licence (for example: IMEI of end user's phone OR MSISDN of end user's phone or email of end user) or one value which applies for several licences (for example: URL of document space for one customer used by all end users) . When customer orders licences he does not provide information about end users as they will be precized later when licences will be associated to end users. For these reasons, realizing resource is a data separated from end user data in the APIs. Partner has to precize during partner's on boarding with Orange how he manages this technical support (one different per user or not , what is this data to allow Orange to control when end user will be attached to the licence, OR one unique value for all licences of customer generated at first order). If partner needs the realizing resource information to create the licences then, he should propose a way to create licences with fake realizing resource values and also he should be able to update this value when end user is linked to the licence.
- Why does orange separate login data from end user's data?
Management of login data is separated from end user's data because login is required to access to licence even if no end user's data is provided. If there is a strict link between login and one of end user's data, partner should identify it during partner's on boarding so that Orange controls end user information required to generate access login.
- How to test API implementation and then indicate that API is in production?
API implemented by partners are tested from Orange's production environment using a fake customer to launch API calls. To declare API to test in a qualification environment, declare an application specialized to test phase and subscribe to business apps API. It will allow you to declare test URI. After test phase, when your API is put in production, create another application and subscribe again to business Apps API to be able to declare production URI. The test application will not be used anymore by Orange (your test URI are no more used by Orange as production URI will replace test URI). Consequently, suppress your test application when production application is created.