• rchoi_zuora
  • NEWBIE
  • 0 Points
  • Member since 2009

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 3
    Questions
  • 1
    Replies
Hi Wonderful Force.com Community!

Question: I'm working with my team to import our Zuora WSDL into Salesforce. It's a lot like the salesforce WSDL -- a base object named zObject, different sub-objects, and a create() call. The Apex2WSDL code works great -- it creates an Account object, the create() call, and even the create element wrapper. 

The callout works as well, but it's missing one thing -- a type attribute on the zObject. For example, the XML looks like:

<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Header><SessionHeader xmlns="http://api.zuora.com/"><session>BLAH</session></SessionHeader></env:Header><env:Body><create xmlns="http://api.zuora.com/"><zObjects><AccountNumber xsi:nil="true" xmlns="http://object.api.zuora.com/" /><Name xmlns="http://object.api.zuora.com/">Dev Test 1</Name></zObjects></create></env:Body></env:Envelope>

As you might imagine, I want to have the XML be:

<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Header><SessionHeader xmlns="http://api.zuora.com/"><session>BLAH</session></SessionHeader></env:Header><env:Body><create xmlns="http://api.zuora.com/"><zObjects type="Account"><AccountNumber xsi:nil="true" xmlns="http://object.api.zuora.com/" /><Name xmlns="http://object.api.zuora.com/">Dev Test 1</Name></zObjects></create></env:Body></env:Envelope>

But I can't seem to figure out how to add the type="Account" part. I tweaked the generated code (messing with Account.apex_schema_type and create_element.zObjects_type_info, yes, a hack) but neither did anything useful. I included the generated code below, in case it's useful.

I guess it comes down to one question: is there a way in the auto-generated code to include custom XML attributes? And if so, what is it?

Thanks in advance!

*r*

------------------

GENERATED CODE:

    public class Account  extends ZObject {
        public String AccountNumber;
        public String Name;
        private String[] AccountNumber_type_info = new String[]{'AccountNumber','http://www.w3.org/2001/XMLSchema','string','0','1','true'};
        private String[] Name_type_info = new String[]{'Name','http://www.w3.org/2001/XMLSchema','string','0','1','true'};
        private String[] apex_schema_type_info = new String[]{'http://object.api.zuora.com/','true','true'};
        private String[] field_order_type_info = new String[]{'AccountNumber','Name'};
    }

        public apiZuoraCom.SaveResult[] create(objectApiZuoraCom.zObject[] zObjects) {
            apiZuoraCom.create_element request_x = new apiZuoraCom.create_element();
            apiZuoraCom.createResponse_element response_x;
            request_x.zObjects = zObjects;
            Map<String, apiZuoraCom.createResponse_element> response_map_x = new Map<String, apiZuoraCom.createResponse_element>();
            response_map_x.put('response_x', response_x);
            WebServiceCallout.invoke(
              this,
              request_x,
              response_map_x,
              new String[]{endpoint_x,
              '',
              'http://api.zuora.com/',
              'create',
              'http://api.zuora.com/',
              'createResponse',
              'apiZuoraCom.createResponse_element'}
            );
            response_x = response_map_x.get('response_x');
            return response_x.result;
        }

    public class create_element {
        public objectApiZuoraCom.zObject[] zObjects;
        private String[] zObjects_type_info = new String[]{'zObjects', 'http://object.api.zuora.com','zObject','0','-1','false'};
        private String[] apex_schema_type_info = new String[]{'http://api.zuora.com/','true','true'};
        private String[] field_order_type_info = new String[]{'zObjects'};
    }

GENERATED XML

<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Header><SessionHeader xmlns="http://api.zuora.com/"><session>BLAH</session></SessionHeader></env:Header><env:Body><create xmlns="http://api.zuora.com/"><zObjects><AccountNumber xsi:nil="true" xmlns="http://object.api.zuora.com/" /><Name xmlns="http://object.api.zuora.com/">Dev Test 1</Name></zObjects></create></env:Body></env:Envelope>



Zuora (www.zuora.com) is looking for a talented, innovated and leadership-minded Force.com engineer to help us extend the reach of our SaaS-based billing business to new and existing Salesforce.com customers. If you’re passionate about technology, maniacally focused on customers, and fearless about leading a transformation, we want to talk to you.

 

What are we looking for? 

 

Ideally, you are/have:

 

 

  • 3-5 years of developing innovative, groundbreaking apps on the Force.com platform (and have results to show for it!)
  • Are a rockstar when it comes to Apex Classes, Triggers, Pages, S-Controls and connection.js
  • Know the fundamentals of web programming -- AJAX, HTTP, HTML, and all that.
  • Know what a managed package is, when to use it, and -- more importantly -- when NOT to use it 
  • Love coding awesome apps, and love leading teams to do the same 
  • Have great ideas, and can run with them to produce great results
  • Works well with limited supervision and can THRIVE at a fast-paced startup!
 

 

 

Who are we?

 

Zuora is the fastest-growing on-demand subscription billing and payment service. The Zuora platform changes the way subscription businesses manage and sell to customers and allows them to bring new products to market in less time, with less hassle. Backed by Benchmark Capital and salesforce.com’s CEO Marc Benioff, Zuora is built from the ground up by SaaS visionaries and veterans from salesforce.com, WebEx, Google and Oracle. Zuora is based in Redwood City, California. 

 

Is this you? Then who can you contact?

 

If you're interested in this awesome opportunity, please send your resume to Ryan Choi (rchoi@zuora.com).

Message Edited by rchoi_zuora on 09-02-2009 11:13 PM
In porting to a managed package, we blocked and tackled a number of issues with prefixes, but there's one hurdle that we can't seem to get over. More specifically,

1. We added a namespace to our dev org (zqu)
2. We packaged up a managed beta and installed in a test org.
3. When we hit the page in our UI (ZuoraQuoteSubmit) in our test org, we got the error
 
"Unknown property 'zqu__Quote__cStandardController.Quote__c'
 
4. This page works in our unmanaged installs, and continues to work in our development org.

In looking a little closer, we noticed that the installation attempted to prepend our package prefix throughout our Apex Page. However, it seems to have done this selectively. For example, our dev code looks something like:

<apex:page standardController="Quote__c" title="Quote" sidebar="false" >
...

var _billtocontactID = "{!Quote__c.BillToContact__r.Id}"; 
var _soldtocontactID = "{!Quote__c.SoldToContact__r.Id}"; 
var _zuoraPaymentMethodID = null; 
var _zuoraPaymentMethod = "{!Quote__c.PaymentMethod__c}";

After installation, the page looks like this in the installed org:
<apex:page standardController="zqu__Quote__c" title="Quote" sidebar="false"> 
	var _billtocontactID = "{!Quote__c.BillToContact__r.Id}";
	var _soldtocontactID = "{!Quote__c.SoldToContact__r.Id}";	var _zuoraPaymentMethodID = null;	var _zuoraPaymentMethod = "{!zqu__Quote__c.zqu__PaymentMethod__c}";
It looks like the installation figured out how to add it to the standard controller (zqu_Quote__c) and one of our merge field references ({!zqu__Quote__c.zqu__PaymentMethod__c}). However, there are two references right in the middle that were not at all affected.

We tried to corrolate this to the types of fields in our Apex page, but it wasn't conclusive; some custom objects had the prefix, some did not. some custom fields had the prefix, some did not. (I've attached the before and after files, cut-and-paste from the SFDC web UI.)

I think we might be missing something, because we don't really understand how the zuora prefix is added. Maybe it's something simple we're missing.
In porting to a managed package, we blocked and tackled a number of issues with prefixes, but there's one hurdle that we can't seem to get over. More specifically,

1. We added a namespace to our dev org (zqu)
2. We packaged up a managed beta and installed in a test org.
3. When we hit the page in our UI (ZuoraQuoteSubmit) in our test org, we got the error
 
"Unknown property 'zqu__Quote__cStandardController.Quote__c'
 
4. This page works in our unmanaged installs, and continues to work in our development org.

In looking a little closer, we noticed that the installation attempted to prepend our package prefix throughout our Apex Page. However, it seems to have done this selectively. For example, our dev code looks something like:

<apex:page standardController="Quote__c" title="Quote" sidebar="false" >
...

var _billtocontactID = "{!Quote__c.BillToContact__r.Id}"; 
var _soldtocontactID = "{!Quote__c.SoldToContact__r.Id}"; 
var _zuoraPaymentMethodID = null; 
var _zuoraPaymentMethod = "{!Quote__c.PaymentMethod__c}";

After installation, the page looks like this in the installed org:
<apex:page standardController="zqu__Quote__c" title="Quote" sidebar="false"> 
	var _billtocontactID = "{!Quote__c.BillToContact__r.Id}";
	var _soldtocontactID = "{!Quote__c.SoldToContact__r.Id}";	var _zuoraPaymentMethodID = null;	var _zuoraPaymentMethod = "{!zqu__Quote__c.zqu__PaymentMethod__c}";
It looks like the installation figured out how to add it to the standard controller (zqu_Quote__c) and one of our merge field references ({!zqu__Quote__c.zqu__PaymentMethod__c}). However, there are two references right in the middle that were not at all affected.

We tried to corrolate this to the types of fields in our Apex page, but it wasn't conclusive; some custom objects had the prefix, some did not. some custom fields had the prefix, some did not. (I've attached the before and after files, cut-and-paste from the SFDC web UI.)

I think we might be missing something, because we don't really understand how the zuora prefix is added. Maybe it's something simple we're missing.