• HealthDetail Development
  • NEWBIE
  • 0 Points
  • Member since 2014
  • HealthDetail


  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 0
    Likes Given
  • 4
    Questions
  • 3
    Replies
Spring '17 included the below. The Apex Limits class doesn't seem to cross namespaces so how can we calculate this? If I had a managed package and wanted to include the non-managed code also executed during my transaction how/can this be done?

"Per-Transaction Certified Managed Package Limits
Certified managed packages—managed packages that have passed the security review for AppExchange—get their own set of limits for most per-transaction limits. Certified managed packages are developed by Salesforce ISV Partners, are installed in your org from Force.com AppExchange, and have unique namespaces.
Here is an example that illustrates the separate certified managed package limits for DML statements. If you install a certified managed package, all the Apex code in that package gets its own 150 DML statements. These DML statements are in addition to the 150 DML statements your org’s native code can execute. This limit increase means more than 150 DML statements can execute during a single transaction if code from the managed package and your native org both execute. Similarly, the certified managed package gets its own 100-SOQL-query limit for synchronous Apex, in addition to the org’s native code limit of 100 SOQL queries.
There’s no limit on the number of certified namespaces that can be invoked in a single transaction. However, the number of operations that can be performed in each namespace must not exceed the per-transaction limits. There’s also a limit on the cumulative number of operations that can be made across namespaces in a transaction. This cumulative limit is 11 times the per-namespace limit. For example, if the per-namespace limit for SOQL queries is 100, a single transaction can perform up to 1,100 SOQL queries. In this case, the cumulative limit is 11 times the per-namespace limit of 100. These queries can be performed across an unlimited number of namespaces, as long as any one namespace doesn't have more than 100 queries. The cumulative limit doesn’t affect limits that are shared across all namespaces, such as the limit on maximum CPU time.
These cross-namespace limits apply only to namespaces in certified managed packages. Namespaces in packages that are not certified don’t have their own separate governor limits. The resources they use continue to count against the same governor limits used by your org's custom code."
I'm not a super experienced developer.

When using Workbench to delete Flows using DestructiveChanges, each of the <members> must be listed. Is there an easy way to get all of the <members> in a retrieve, or other method, in a format I can reuse in the DestructiveChanges? I must be missing something.
<members>Flow1-1</members>
<members>Flow1-2</members>
Now if I do a retrieve I get all the Flows in the org but have to manually enter the <members> and versions.
Code coverage in our Developer org is 89%. Uploaded package today and uploads fine. When we add a Custom SystemAdmin Permission set, upload fails with 5% coverage. Any ideas why that might be or how to troubleshoot?
I believe this is a Salesforce issue but will post here since they are insisting I do so.

We have developed a managed package ~4 yrs ago. On AppExchange, etc. We have been able to upload new versions fine if they just contain native changes such as new fields, objects, etc. Recently we added a Permission Set. The package upload is failing with error of 1% test coverage. Seems to happen with any new Apex added.

Our org has 90% coverage. We have tried recompiling all classes and rerunning many times. We are not accidentally pulling anything else into the package, it's just 1 permission set. We tried removing the Perm set and just adding a 2 line Apex class and upload to beta. Fails for same reason. Seems to run tests when Apex added...but calc is wrong. Any ideas?
Before we turn this on in production (which you cannot turn back off), we just wanted to verify that our current deployment process that using the Migration Tool will not be affected.

We assume we can use both Salesforce DX and the Migration Tool at the same time but wanted to verify that assumption before making this irrevocable decision.
Code coverage in our Developer org is 89%. Uploaded package today and uploads fine. When we add a Custom SystemAdmin Permission set, upload fails with 5% coverage. Any ideas why that might be or how to troubleshoot?
I believe this is a Salesforce issue but will post here since they are insisting I do so.

We have developed a managed package ~4 yrs ago. On AppExchange, etc. We have been able to upload new versions fine if they just contain native changes such as new fields, objects, etc. Recently we added a Permission Set. The package upload is failing with error of 1% test coverage. Seems to happen with any new Apex added.

Our org has 90% coverage. We have tried recompiling all classes and rerunning many times. We are not accidentally pulling anything else into the package, it's just 1 permission set. We tried removing the Perm set and just adding a 2 line Apex class and upload to beta. Fails for same reason. Seems to run tests when Apex added...but calc is wrong. Any ideas?