Product Invoices are created in ZUORA system. A nightly scheduled job in SAP executes the Wrapper program which triggers the PI system to communicate with ZUORA system with Query API and fetches the data pertaining to ZUORA Invoices.
Once the data is fetched from ZUORA system, data is collated in internal tables of Wrapper program. Along with ZUORA invoice data, some default data in SAP needs to be added to internal table. Once all the required data is collected to create a Billing Request and Invoice, data is passed to Sales order Create BAPI and Invoice create BAPI to raise Billing request and invoice.
Once the Invoice is raised and posted to accounting, transmission log has to be passed back to ZUORA system via PI system.
Proposed Integration Framework and Architecture:
Integration framework in SAP ECC has classified based on objects and each proxy is generated for specific object information fetching, Wrapper program can be schedule at specific time interval as it’s designed to fetch ZUORA object information (i.e. Invoice/Account/Invoice Item etc…) in query form and post retrieved data to respective BAPI fields.
Query needs to be formed with requested fields in wrapper program and this should be passed to corresponding proxy as querycall() request.
Wrapper needs to perform following to retrieve with query call, this is sync call.
- Fetch the Invoice header data(Id, Account Id , Inovoice Number, Due date, Invoice Date where Status = ‘Posted’ ) from Zuora system by using the method SI_OUTBOUND_INVOICEZCO_SI_OUTBOUND_INVOICE
and pick the data into internal table it_invhead.
- Fetch the Invoice item data(data(InvoiceId, RatePlanChargeId, Quantity, UOM,SI_OUTBOUND_INVOICE_ITEM_DETAI of class ZCO_SI_OUTBOUND_INVOICE_ITEM_D and
Pick the data into internal table it_invitem.
Integration Framework in SAP PI is designed based on object categories available and needs to be access from ZUORA API using SOAP API call, this require to download third-party’s WSDL file, this is a generic WSDL for all the SOAP API calls.
In order to perform querycall() there is need to tweak WSDL structure so that it can accommodate appropriate response from third-party, this step enables to perform response mapping from third-party to ECC system, unless we perform this step its not feasible to map response payload.
As shown in the following screen shot zObject element has dynamic string, this needs to be replaced according to specific object in query Response as shown in following figure.
Once you have service interface created upon modified WSDL we are good to proceed with mapping, as third-party also has session handling while requesting the response, we need to have the login service call followed by request querycall();
After analyzing ZUORA SOAP API calls, its been decided to take this approach as this can be done with service calls and architecture is designed based on this keeping in mind points like from SAP ECC synchronous and asynchronous calls can be made based on object/transaction performed and also decouple business logic from integration so that ECC side person implementing business logic should not aware or bother about ZUORA API functionality.
Proxy approached is adopted for this, each proxy call is make for transaction performed, for instance to fetch Invoice/InvoiceItem details proxy is generated for Invoice/InvoiceIntem so that this can be used in wrapper program, wsdls needs to be modified specific to objects to be access and imported to PI system to create service interface upon them. Following is the designed architecture overview for this integration.
- Wrapper from ECC makes proxy calls to corresponding objects in ZUORA system, these are send via PI as SOAP calls.
- Once query request received by SAP PI system, system invokes login call to third-party system and gets sessionid as loginresponse.
- This session id is embedded with query request and sent to third-party as part of fetch data for specific object, during this process java mapping enables to modify the content acceding to third-party soap header format.
- Once the response is received to SAP PI, modified XSD structure imported as WSDLS in SAP PI system catches the response and forwards it for mapping.
- ECC wrapper receives the response and process the fetched data for specific object and used to pass it to BAPI for creating Invoice and InvoiceItems.
Following are the implantation steps to fetch Invoice/Invoice Item data from ZUORA.
Step: 1 Importing and modifying WSDL specific to Objects needs to be access from ZUORA API for SOAP call.
Replace element type to Account, so PI can catch the response from ZUORA and perform mapping on the response payload.
<element name=”done” type=”xs:boolean”/>
<element name=”queryLocator” type=”zns:QueryLocator” nillable=”true”/>
<element name=”records” type=”ons:Account” nillable=”true” minOccurs=”0″ maxOccurs=”unbounded”/>
<element name=”size” type=”xs:int”/>
Step:2 Once the WSDL changes are performed to specific objects (i.e Account, Invoice,InvoiceAdjusment) import these WSDLs in SAP PI as shown in following screenshot.
Step:3 As part of designing framework we need to create specifi namespace for each object to be fectched and create proxy on these objects.
Once the proxies are generated, wrapper program is used to construct query to fetch data as shown In following screenshot.
Once the data is fetched we can call the proxy to send the request with formed query string, we can have multiple proxy calls in wrapper program so that multiple calls to ZURO API can be made to fetch data to pass to Invoice creation BAPI.
Step:4 Third party cloud access can be done using login credential and data fetch request needs to be send with sessionid(i.e login response from third-party system). Java mapping is implemented to accommodate sessionid with query request and also embed soap header with query request as this should be allowed by ZUORA API.
Following code screenshot is used to embed login session is to request.
Following Code screenshot is used to strip off xml and embed soap header.
Step: 5 SOAP receiver channel needs to be configured with SSL certificates for authentication. In order to enable this authentication its necessary to have certificate from clients and once we have these certificates we need to import those in ketstore and maintain same in communication channel.