Help Me Understand..

[Former Member]

So over the Past few months I believe the Development studio has taken a turn for the worse.. And maybe it is just me not understanding.( yes I have read all the emails and such on it). But No-one has yet to provide me with a good reason why Scaleable solutions are History.  How does a "Template" even compare.

From what I understand (possibly Wrong) these are the issues with Templates replacing Scalable Solutions

• No Key user Tools (reports/forms....)
• No Modification of Existing Byd Screens
• No Mass Patch System meaning if there is an upgrade/Fix to the Template Every individual System would have to be manually modified and upgraded..(How is this sustainable?)
• The whole system is moving towards a Customer-Specific model.. where Mass Marketed and/or vertical Add-ons are not really feasible anymore. as there is no way to mass manage them.
• Templates will be on the store (sometime) But how will this work if our Solution includes enhancements to Existing UIs , Mashups, forms, reports and how will updates/Patches work. In a store model the Partner should not have to access the Customers Tenant at all.
• And If Scaleable Solutions are Still around Why would I need Permission Before Developing shouldn't it be a Store Approval process after development like every other Store / Development system. and like it has been.. Have people been abusing it (by the number of actual store apps I Doubt that)

I am looking for a good explanation of where things are going and have yet to hear one.  I work at the Largest Re-seller of ByDesign in the World and the higher ups here want me to tell them my opinion.. While I try to be non Bias (I have worked and reviewed some competing APIs and SDKs)  ByDesign appears to be really behind the rest and not moving forward... I have been involved for several years and was part of the first American group to preview the Studio.  There have been a lot of changes which are good,(Many are still bad like cross BU communication, UI Events...) however I am dumbfounded at this new approach.

Don't get me wrong I like templates and believe they have their place but I do not feel they are a replacement for scalable solutions unless the points above are addressed.

I could be crazy here and just not getting it.. So I am starting this discussion as a means to "Convince" myself and help me sleep better at night. 

So please give me your opinions on the matter.

[stefan_miller]

Hi William,

maybe our (PDI) communication was wrong or misleading. We do not plan to stop support for scalable partner solutions nor plan to replace existing ones with templates. Templates is about code reuse - on the SAP Store partners can offer 'complete' solutions only.

What we are planning and actually developing is scalable solutions based on 'custom specific solution technology'. We actually support partners to migrate existing scalable solutions to custom specific (as many of the existing scalable solutions are custom specific ones 'by nature') and we'll also support the migration to new scalable technology in the near future.

The reason 'behind' the incident process to create scalable solutions is to get in touch with partners for a discussion about an optimal addon solution type choice for the time being.

[Former Member]

Thanks Stefan,

I read the email that you sent to Curtis.. Thank you for the response... While I am excited for the future.. I wish some advance notice would be available when these type of major changes happen..In this case I downloaded a new version of the Studio and was confronted with the change.

on a different note you we brought up this concern

• Cross Deployment Unit Communication. We understand it’s still not possible create a business object that is in a different BO than the one you’re in.

That’s possible and sdk/studio supports messages for the same (standard ByD architecture)

What the actual concern is that when a "Message" is sent from one Unit to another there is not Communication back to the calling process as to weather that was successful or not or the ID/UUID of the BO created is not readily accessible. If this has changed can you point me to the documentation of the change.

[Former Member]

Hi Stefan, I just read your post and I pretty exited for the change of focus on scalable solution, also I just was in the onDemand Studio workshop and I hear that SAP's working on it, so that's a great new, what I'd like to know is, how can I get more info about it?

Best regards.

[ThomasSchneider]

Hi Billy,

the system infrastructure ensures that the message is delivered, this means that the receiver BO is created or updated. If the update cannot be sucessfully executed, the system will react accodingly:

- if there is a temporary issue (for example receiver object is locked), the system will retry automtically

- if there is a permament issue, for example an error message that prevents the save, the system will create a business task (see documentation: Service Integration -> Define Service Integration Error Handling) or an incident. Based on the task/incident, the user can take actions such as retry, correct the data in the sender document & retry, correct the error in the receiver.

To check the status (& ID/UUID) of the receiver document, you can do the following:

a) Cross DU read is allowed, so you can read the ID/UUID of the receiver document by the ID of the sender document (typically you will transfer the ID of the sender document to the receiver document)

b) You can send an acknoledgement from the receiver back to the original sender BO. This will be send after the save of the receiver document. This is how SAP does the process flow across DU boundaries.

Best regards,

Thomas

.

[Former Member]

Billy,

I agree 100%. I honestly get bummed out whenever I get a customization request now because I am so sick of the Studio. I also do not understand this new model that puts so much red tap into getting a solution to the store. To be fair, I have made a lot more money on customer-specific solutions, but I would love to use other partner apps for my clients' needs.

Judson