function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Dr. Thomas MillerDr. Thomas Miller 

DebuggingHeader

The DebuggingHeader in the SOAP API is specified in
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/sforce_api_header_debuggingheader.htm. The page says that debugLevel attribute is deprecated and categories attribute should be used instead.
The latest partner WSDL however defines
           <element name="DebuggingHeader">
                <complexType>
                    <sequence>
                        <element name="debugLevel" type="tns:DebugLevel"/>
                    </sequence>
                </complexType>
            </element>

So what is the correct way to use this header?
 
Daniel BallingerDaniel Ballinger
Firstly, you've linked to documentation form the Apex API WSDL. This has largely been replaced by the Tooling and Metatadata APIs.

That said, the functionality is still in the WSDL as you can adjust the API version on the request to access the deprecated functionality. If you choose an old enough API version you can still use the debugLevel element when executing tests or running anonymous Apex.

With all current API versions you can safely set the debugLevel to LogType.None and then set the actual required levels via the categories. As I mentioned in your other question. Watch out for the TraceFlag overriding the DebuggingHeader (http://salesforce.stackexchange.com/q/77645/102).
Dr. Thomas MillerDr. Thomas Miller
Hi Daniel,
your answer raises several new questions.
i) "... has largely been replaced by the Tooling and Matadata API". According to all docs I have seen the SOAP API described by Enterprise WSDL or Partner WSDL is still the defined way to communicate with your Salesforce org (if you aren't writing dev tools or modifying the org's schema through the API). Looking into the Tooling API I do not see this as a replacement for a 3rd party integration used e.g. to create records of custom objects.
ii) I want to work with the newest API version - but I would prefer not to modify the WSDL myself to get it in line with the documentation. Copying the DebuggingHeader, LogCategory, LogCategoryLevel and LogType definitions from the Tooling API WSDL into the Partner WSDL is something that Salesforce should do, not me.
Daniel BallingerDaniel Ballinger
You are correct in that the Tooling and Metadata API are primarily for the creating developer style tools. The Apex API (which you linked to) is also included in this category.

If you want to work with data in an org then the Partner API or Enterprise API are the way to go. You should not need to modify the latest WSDL to work with it. There are a few exceptions based on support be the consuming environment. E.g. .NET doesn't support all the WSDL constructs as they are currently used.

I've been using the Partner API from .NET for many years now and I've never needed to modify the WSDL to work with it. That said, the latest version of the WSDL may contain a number of deprecated elements. You can safely ignore them and use the core functionality.