Let's see how this is done. First of all, a new custom business service needs to be created:
Now create a new custom method for this service:
Finally, create the following method arguments for this new method:
Ok. Now for the script. The script I will about to specify has several features:
- Calls the Server Requests business service which runs a workflow process in the Workflow Process Manager server somponent in its own thread
- Input Properties to the Server Requests business service cannot be passed through the business service context attribute of an Action, as Siebel expects these properties as a child property set.
- Can be called from a Run Time Event-Action by setting all properties as Profile Attributes
- Can be called from a business service or workflow process by setting all properties directly as Input properties
- Takes input properties, either from from profile attributes or from input property set, and passes them as custom input properties to a workflow process.
- Profile Attribute name will be "PassThrough1", for instance, and the profile attribute value must be in the format "
", " " - Can optionally specify a specific application server to run on, otherwise will allow the load balancer to assign the server
- By default, will run in Remote Synchronous mode if user is connected, otherwise will run Remote Asynchronously.
- Can optionally be set to be run as explicitly Remote Asynchronously
This is written in eScript and there are plenty of different ways to go about this, but this is a rough guide (actually, not so rough):
Hi Mik,
ReplyDeleteGreat blog, great stuff you are introducing to the audience!
I have this question regarding WFs, which may turn out to be something very small, but essential. When you have a WF called from RTE, WF Policy the Object Id is populated with the Id of the current object Id or base table row Id. However, when you have for example a WF called by an HTTP inbound receiver named subsys, you may not be able to populate the Object Id due to the fact that the external application does not care about your Id for the record (it knows the Integration Id for example). In such cases when you try to use the Siebel Operation Step.Query method having the Integration Id as a search spec. it will error out because the WF (based on the Account BO let's say) will need its Object Id for Account. Am I correct? Is there any scriptless way to workaround that behaviour?
Thanks for the help and keep on going with those great articles,
Svetlin
There may be an easier solution, but I think you just need to query for the Object Id first, probably using EAI Siebel Adapter, Query method. If you are using HTTP I am guessing this is an EAI scenario where you have an inbound message. Integration Id, or whatever unique logical key is embedded in the message, can be used to query for the record using Siebel Adapter. One of the output parameters of this BS step is the Object Id which you can then set and use appropriately later in the Workflow.
ReplyDeleteHi Mik,
ReplyDeleteThanks for the reply. I like your easier solution, which is a helper in this case.
Sorry, it is off the topic, but I wondered, if know from your vast experience, any way to open a post 7.7 .dbf not using the USER/PASS or DBA/ENTERPRISE_NAME. I have this wierd problem with the client and I am searching an alternative ways to open the .dbf at least. The upper two credential combinations also doesn't work for me.
Regards,
Svetlin
I am not really certain, but in some scenarios, you can try DBA/SQL.
ReplyDeleteThe DBA/SQL is valid for Siebel 7.0 till 7.5.x. Starting 7.7 the combination is set to DBA/ENTERPRISE_NAME, if the ENTERPRISE_NAME is shorter than 8 character it is completed with 1234...till the eight characted. e.g. the enterprise name is SIEBEL, the pass would SIEBEL12. Also the DBA pass can be set to a diffrent value with a DB Extract for the respective Siebel client.
ReplyDeleteUnfortunately, all that information did not help to succeed and I am about to leave this issue behind.
Thanks,
Svetlin