Orange Business Applications France 2.2

id is the identifier generated by the system which receives the POST request (i.e the system that creates the resource). ExternalReference  sub-ressource contains the identifier used by the system which is sending the POST request. The objective is to have for some resources both Orange and partner identifiers for the same resource. To know which are the id filled in the request and the response, see getting advanced document whose link is provided in the 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 response.

productRefId is the identifier of the licenses fleet. productRefId is generated by partner when returning the response 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 fleet 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 a new productRefId to integrate these new licences. In all cases, the productRefId used to integrate new licences is sent back in the response. As productRefId, partner has choice between using technical id of the customer, 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 order 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.

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 whose link is provided in the getting started precizes clearly which are the data provided or not in the request and response of API calls.

If the response provided by partner is not synchronous, the status of the synchrounous call back is "acknowledged". It means that the synchronous response does not contain business values, it is only a technical response to indicate that the call well happened. In this case, the business responser is provided later by partner calling the "event" resource provided inside ProductOrdering and UserService APIs. Inside "event", there is a productOrder or a userService resource to provide the business response when the business process to manage the request was ended.

If the response provided by partner is synchronous, then the "event" call is not implemented by partner. The business response is directly provided inside the response of ProductOrder and UserService calls. "Acknowledged" status is never used in this case.

Yes, ProductOrdering API is used both to create a customer  and also to manage orders of one customer (initial order, adding of new licences inside a customer's fleet). Depending on the goal of the call, provided data are different. The document "getting advanced" whose link is provided in the getting started provides all details about provided data depending on the goal of the API call.

Realizing resource is the technical support of licenses of partner services. Depending on the partner service, it could be a specific value per delivered license (for example: IMEI of end user phone or MSISDN of end user phone or email of end user) or one value which applies for several licenses (for example: URL of document space for one customer used by all end users). When customer orders licenses, he doesn't provide information about end users as they will be precised later when licenses will be assigned to end users. For these reasons, realizing resource is a data separated from end user data in the APIs. Partner has to precise during partner 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 assigned to the license, OR one unique value for all licenses of customer generated at first order). If partner needs the realizing resource information to create the licenses then, he should propose a way to create licenses with fake realizing resource values and also he should be able to update this value when end user is linked to the license.

Management of login data is separated from end user data because login is required to access to license even if no end user data is provided. If there is a strict link between login and one of end user data, partner should identify it during partner on boarding so that Orange controls end user information required to generate access login.

During the development phase, in addition to the tests performed in its IT, the partner could use a tool provided by Orange: Partner Onboarding Helper. This application allows to perform in complete autonomy a first level of tests on the development done to integrate part of functionalities of the Orange Business Applications France API. it allows to simulate the API calls made in synchronous mode by the Orange IT without asking Orange to make these calls. The aim is to check that the data provided in the response is consistent with what Orange SI expects. To obtain the installation procedure and a user guide for this application, send an email at shine2.onboarding@orange.com.

Then, once your APIs are developed, tested and published, you will start a new phase of tests with Orange IT: the integration tests. Because, during this integration phase, the API calls are initiated by Orange, you must send an email at shine2.onboarding@orange.com to begin testing.

The integration tests are performed in two steps:

Step 1: tests on a non-production environment on Orange side. All the use cases implemented are tested to validate the APIs developments done by the partner and to validate the use of the event implemented by Orange if the parner manages asynchronous response. On the partner side, we recommend performing the tests in a development environment.

Step 2: once all the tests performed during step 1 are OK, tests are now performed on the production environment on Orange side using a simulated customer. Only some functional tests are performed to verify that all is OK.

After the validation tests have been completed, the operational phase may start as defined in the joint agreement (between your company and Orange). The prerequisite is to publish your APIs to your production environment (cf. Publish and subscribe to the APIs as it can require to create an application again if you first create an application for your development environment)