I have built a service (service package, service, service activity to create a new case) under FW layer. When I switch to the impl layer, I could not see them under service definition. should I have to create another set of service package, service under impl layer in order to use?
By Definition, you won't be able to see it. There is no need to create unless specifically required. Service rules kept in FW layer should be able to create cases in Impl layer. You have to send the class name as a parameter to the service activity which in turn will create the case (may be calling AddWork). Pls share your full requirement if this answer is not clear.
Thanks for you reply. It is helpful. Yes, there will be one service activity take the parameters. I still have to create two services, one for FW and the other for Impl since this is the place to pass the parameter (class name) in, right? For the service package, one can hold both services.
Service should be created in FW layer and the service activity should take the class name (Impl layer name) as parameter. By PRPC design principle It is not required to maintain services in different layers and you FW application should run as an application irrespective of Impl layer and Impl application
If a service needs immediate access to a ruleset that is unique to a particular application (I am ignoring whether or not that application is considered the framework for some other application) then the service's Service Package's access group must point to that application pure and simple.
A service could queue a request that contains sufficient information that an Advanced Agent with the appropriate Access Group would know it should process the request as opposed to an Advanced Agent that has a different Access Group.
Or you could have a single application that, based on one or more "clues" within the request, either employs circumstancing or uses DCR to create and/or query pattern-inheritance-based classes as needed. Specialized classes can be placed in additional rulesets -- every business logic work/data rule does not have to be placed in the same ruleset.
As a last resort you could attempt to create a single "mega" application that contains every ruleset that contains "implementation" classes that directly extend "framework" classes, replying on DCR to point to the correct "implementation" class to use. This may or may not prove difficult to maintain. Care must be taken to avoid using ruleset overrides.
In my scenario, at FW layer there are two Case Types: ORG-FW-BPMFW-Work-Case-Profit and ORG-FW-BPMFW-Work-Case-NonProfit.
A SOAP service is provided to create the cases by receiving the xml payload.
I created service activity (CreateNewCase that is calling svcAddWorkObject) at ORG-FW-BPMFW-Work-Case to have two parameters to receive the class names. Inside activity, based on parsed information (e.g type) to decide which case type to be created before calling svcAddWorkObject.
Meanwhile, I also have IMPL Layer case type: ORG-DIV-BPM-Work-Case-Profit and ORG-DIV-BPM-Work-Case-NonProfit.
Since the Service rule is the only place to pass the parameters to the activity. I need to create a Service Rule under IMPL layer RuleSet (using same ORG-FW-BPMFW-Work-Case as primary page and same activity) and pass the IMPL class names as parameter in order to create IMPL case type.
I don’t think we can pass the parameter via the Service rule.
Instead of trying to pass parameters, a better solution may be to use DCR and rules resolution to determine the class names. A service package (with Access group / application / rulesets) must exist at each layer you wish to invoke the service. Rule resolution can use this to determine the most specific data transform to populate the DCR values. Assuming you are trying to invoke the service at the fw or impl layer, a data transform of the same name would exist in the respective ruleset for each layer, thus populating the DCR values appropriately.