Hi there AppWorks fans,
Welcome to a new installment of AppWorks tips.
It’s always a good thing to know your tooling enough to get the most out of it. So, for today we cover the most important Explorer artifacts. We will explain them and if needed we do a small deep dive on them or postpone the deep dive to another post. This depends a bit on the size/weight of the artifacts as some a pretty simple to understand and some will need some extra knowledge sharing. But as always…
Let get right into it…
As a first note I want to start with some categorization as this post went larger than expected. So, behind each header you will see the categorizations like this:
- LOW_CODE: these are the most important artifact (I counted 11) for us low-code developers
- BPM: when it has to do with processes, BAM or MDM (You will learn about these abbreviations soon!)
- SERVICES: when services are involved for registering, testing and authentication
- ALL_USERS: are for all users available
- ADMIN: for the administrators of the AppWorks platform to manage things!
- RULES: artifacts specific for rules (you’ll learn about rules in other posts too)
- SCHEDULES: artifacts specific for schedules (and you’ll learn also about these in other posts)
- AUDIT: when auditing is required in the solution.
But now…start the VM with the AppWorks platform and this time we start with the ‘awdev’ account with only the Developer role applied. We will also cover the ‘awadmin’ account with the Administration role and the sysadmin account for other related artifacts.
So, the artifacts available for the ‘Developer’ role
The CoBOC abbreviation stands for Collaborative Business Object Cache and is used to create and maintain business objects (or in other words our ‘entities’) that are crafted in the AppWorks solution. As we have a much nicer UI for crafting our entities this artifact is “deprecated” now. Just leave it there in its deprecation state.
To customize you Web services, but for now you will end up with this message. Enough for now and we’ll cover this one when we start consumer webservices!
This is the only artifact available for all AppWorks users. All tasks/notifications that should be handled by a user will land in this artifact. Normally will not be used by normal users as they will use the front-end UI from the /app/start URL where we can also handle tasks. The same for this artifact, we will cover it once we start to play with BPM and generate some tasks for our users.
This artifact should be familiar to you as we used it already when we created a new ‘Entity’. Only during our entity creation, we initialized this artifact by right-clicking our ‘entities’ folder from our project within the ‘Workspace Documents’ artifact. Now we just found a quick way to start other types of documents also. Like for example a BPM flow. Every type of document that you save will be stored again in our ‘Workspace Documents’ artifact. You will never get rid of the ‘Workspace Documents’ artifact! 🤟
Also note that this artifact will by default initialize your default workspace already. If you don’t have a default workspace selected it will pop-up with your workspace selection panel, so the artifact ‘knows’ where to save your brand-new document.
To manage externally published services. Also, here it is required to have an UDDI registry like we also need for the ‘External Services Configuration’ artifact. We cover it later during our services journey.
You can execute your defined rules on an XML Schema Description object (This has nothing to do with entities!). These are not the rules you can create with the entity building block ‘rule’, but these are rules created by the ‘New Document’ artifact where you need to use the type ‘Rule’. These screens look like this, but we don’t do a deeper dive here and follow this one up in another post.
Rules are also used in combination with ‘Decision tables’ in BPM where you can use more advanced rule-based decisions on whether you should go left/right in the flow. A rule is based on an input schema, the XSD!
With the ‘New Document’ artifact it is possible the create a ‘Schedule’ type of document. It looks like this:
This ‘Schedule Manager’ artifact will give an overview of your schedules. The how/when/what and why will be covered in another post, but now we know it’s possible to do ‘scheduled’ things in the system…?
Our tool for testing SOAP services…and more specific…the services that you’ve exposed from your own organization! It can also do the same kind of trick as the ‘Web Service Interface Explorer’ artifact from the next section can do!
Now it is empty as no services are exposed yet, but once we start doing this, we will also start using this ‘Service Test Tool’. We can for example expose all the CRUD services on an entity and execute on them with this tool…nice…When can we start shining with this stuff?…When the time is ready my AppWorks fans! 😎
Also, this is a number 1 tool when we start with webservices. All services can be easily be found here and when you right click on one you can ‘Test’ it the same way as we do with the ‘Service Test Tool’ artifact. So, it’s what it says it is: An interface explorer for the web services!
For a small test we can for example search for keyword ‘getUserDetails’, mark the ‘Starts With’ and search in the ‘Web Service Operation’ pool to find a small list of usable services.
Now hit that ‘Test’ action to get the next screen for testing the SOAP request. Modify it with this content to get some nice information response and hit the ‘Invoke’ button.
Click on the ‘Received’ message to get a view of the SOAP message with all the valuable information.
The artifact for managing (stop/start and create new) running applications and deployed web libraries that run on our AppWorks platform. There is also a possibility to enable debug and spy options. Nice to know it’s here, but we leave it for how.
Here it is…our most beloved low-coding artifact!…Does it need any explanation after all the hard work we already did on all the other posts on this side? Let me know in the comments below.
Behind our platform we have an XMLStore available. This is a kind of XML database where all kind of settings will be saved done in the UI. You can add new folders and add new XML documents to it if you like and you should also be able to read from this store from you AppWorks solution. The how/when and what will also be covered in another post. Leave the ‘Cordys’ and ‘OpenText’ folders for what they are.
An extra note here is that also ‘xForms’ created with the ‘xForms designer’ are saved in this XML Store. These xForms can also be re-used in the ‘XForm panel’ within a layout building block of an entity…Yes…It’s on the backlog!
And as promised: The artifacts for the ‘Administrator’ role
Here we can check out the status of our deployment procedure from our application. An application is nothing more than a kind of ZIP file that is injected/imported into the platform and gets deployed on it. Ready to be used for our end-users. This makes it possible to bring something nicely to the next environment like for example TEST or the other environments in the Development|Test|Education|Acceptance|Production deployment street.
This ZIP file is better known as an ‘Cordys Application Package’ file with the extension .cap. This .cap file package can be generated and downloaded from a project folder like we created in our workspace in the other posts.
A full package deployment will be done in another post and this artifact will monitor it as the real deployment will be done from the ‘System’ organization as you will see later in this post!
An extra ‘insiders’ note is that most .cap files are installed with a ‘shared’ type and will only be shown when logged in to the ‘system’ organization!
Once your package is deployed on the AppWorks platform you can use this artifact to publish it to the organization so your end-users can start using it. Also, this we will be seen in a closer look when we start deploying something real.
First of all you need to have Audit permission as role, but we have that with the ‘awadmin’ user and second of all is that the ‘Auditing’ service must be up and running which is disabled by default (Check that out in the ‘System Resource Manager’ artifact) because auditing takes a lot of space. But once up and running you should be able to view all kind of information that is enabled by the ‘Audit Configuration’ artifact in the system organization and only by the ‘sysadmin’ account!
For this to work you need to deploy the ‘Cordys BAM MDM Model’ package first with the ‘Application Deployer’ artifact, but for this to work you need a to start the disabled Business Activity Monitor service, the ‘MDM Hub Publisher’ service and the ‘MDM Service’ service (this last one will start with the ‘MDM Hub publisher’) from the ‘System Resource Manager’. And if you followed the deployment of the ‘BAM MDM Model’ you will also start to see a new service called ‘MDM Spoke Publisher’.
As I read this back it sounds complex, but it’s just a bunch off helper services to support the BAM features. I will make a separate post out of this where we start to play with these settings, but I was able to make this artifact error-free within 10 minutes, so you should also be able to do that. Otherwise…Wait for that post! 🧐
Only now we didn’t create an BPM processes yet, so there is also not a lot the monitor…
Note that the purpose of a business case is to weigh costs of undertaking the project against the expectations of the project benefits when it is completed.
As we don’t have any case models in the system yet, we would see any instances…duh!
This artifact gives you inside in the transactions being done in a BPM, but as the documentation from OpenText is telling me this we can skip this artifact.
For this to work you need to have an WS-AppServer service group. To create one, you need to be in the ‘System Resource Manager’ artifact where make a new service group of type ‘WS-AppServer’.
Try it out yourself if you like for now as we will create a new post out of it. If you also create one with a database configured, you can read out the database with this artifact…how handy! The database connection information can be found when you look in the properties of the ‘CoBOC’ service.
And this is how it can look like in the end
Here all the deployed BPM processes can be managed. You will see some default processes that are already installed on the platform. Other will start to pop-up when you create new processes.
You can mark a process and do some actions like viewing the graphical design, viewing running instances of the process, enabling monitoring, view audit (if configured) and give authorization who can instantiate the process.
When we start using processes will take a closer look again at this artifact.
Before the artifact can be used you need to run the ‘Rule Management’ which can be found in the ‘System Resource Manager’ artifact and can only be started from the ‘System’ organization!
This artifact is now empty as no rules are created for out solution! New rules can be created from the ‘New Document’ artifact where create a new document of type ‘Rule’. Also, the ‘Rule Test Tool’ describes on this page can be used to test the rules. The ‘Deployed Rules’ artifact gives us a nice overview what is deployed.
Here we can manage our FTP server connection that can be used on our Platform. It’s clean for now, but we’ll install an FTP server on our image in another post and show you how it can be configured here and how you can use it your solution.
The first thing you will see here is this message…
Not very useful, but it can be fixed by creating a new service group in again the ‘System Resource Manager’ artifact with the connector type ‘OpenText HTTP Connector’. You can start doing it on your own, but we will explain this in other post.
This artifact just makes it possible to manage the HTTP connections that can be used within the platform. Just like we can manage FTP connection and the next iHub connection.
If you have an iHub instance running, you can point to it with this connection manager. iHub is a separate software package that makes it possible to analyze your data and report over it. These reports can then be integrated in the AppWorks solution. Nice stuff to dive in to, but not for now. This will be a new post!
Again, this is a manager application and this time it can manage tasks that are assigned to inactive users which can always happen. With this artifact you can assign these tasks to other users that are active in the system. So, typically an administration task.
This artifact lets you browse or edit (if authorized) the directory services from Cordys (this is our CARS installation for our AppWorks platform). We will probably not use this artifact a lot as normally this authentication is handled with OTDS.
A very handy artifact where can get deeper insides on what is going on our platform. Crucial for administrators, but also nice to have for us low-code developers.
When you open the artifact, it shows the ERROR messages by default, but there is more to explore by hitting the collapse buttons for ‘Search filters’ and ‘Details’ at the bottom. I don’t know why these are not expanded by default, but it’s what it is. Also make note of the multiple pages arrows.
This is the ‘Search filters’ expanded where can also mark the ‘Advanced search’ option it gives you even the possibility to customize the search by hitting that ‘Edit and search’ button where you dive into the XML request.
And then there is the ‘Details’ panel expanded for a specific ERROR (doesn’t matter what it says…for now)
The Master Data Management administration settings artifact…WTF is MDM!? It’s just all the persistent object data generated in the solution and synchronized to other data sources (like for example BAM)….You know BAM?…It’s just the monitoring information of our process information.
Next to the process information also MDM information (named ‘MDM entities’) is saved in a data source! And with all this data (synchronized between several data sources) we can again generate nice reports with related dashboards.
This artifact configures the synchronization, log and notification settings.
A running process instance can be archived when it is no longer active or if it can’t be restarted (Also a completed process state is something that is no longer active). What information should be stored for these processes is defined in the archive policy in this artifact. Not only information about the process will be archived, but also the model data used in that process.
The processes with their selectable status can be defined in a policy. A policy can be run manually, but also automatically based on schedules and timelines. And once the processes are archived, they are removed from the repository and can be restored into the repository with the ‘Restore process instances’ artifact.
We will play with this artifact once we start using BPM processes in the solution.
Also, here…When we start to play with BPM our running process instances will pop-up in this artifact and we can take a deeper dive into them. Great functionality for an administrator to get best insights on the running process for the platform.
This is the other end from the ‘Process Archival Manager’ where we can restore them back into the repository with their archived state…Also play stuff when we do BPM things!
This is the artifact where we can add identity providers (systems that verify if you are, who you say you are) to the platform. We will start using the when we start authentication with OpenText Directory Services, but others (like SAML 2.0 and OAuth) can also be added.
Security also comes with a bunch of certificates that can also be managed with this artifact.
This is an artifact that is supported for the ‘State SyncUp’. This last one is responsible for keeping stuff in synch in distributed applications. This gets in the picture when we have big systems where high availability and fail over are features to be implemented. Not for now, so we just skip this one.
All services, interfaces and connection points are managed in this artifact. We saw this artifact already as a dependency for other artifacts, so this is the big spider that keeps it all together. Services can be stopped, started, monitored and configured. We’ll see we also need to add some new services to the list when we are required to use a certain connector. Like for example the ‘WS-AppServer’ that is almost required for every AppWorks platform.
Great artifact for testing the performance of webservices! Just type in the URL, numbers of connection, calls per connection and start breaking things with the shining ‘START’ button. Lucky we also have a ‘STOP’ function!
It’s standing for Universal Description, Discovery, and Integration. The artifact manages the UDDI registry instances that can be consumed by the platform. An UDDI registry is nothing more than a kind of telephone book we all services can be registered and looked up again. jUDDI is an open source implementation that we will start using in another post.
There they are again…Our beloved users that we configured in another post. New users can be added here, but as told several times we will start using OTDS for managing our users and then they will be pushed into the platform from the OTDS perspective.
Here we can view some statistical data for our platform. No fancy-pansy stuff, but good to know it’s available…You’ll never know when it comes in handy.
Other artifact are already described in the ‘Developer’ role section.
And the cherry on the cake: The rest of the artifacts for the ‘Sysadmin’ role in the ‘System’ organization
If there is an artifact ‘Audit Viewer’ then is should also be something to configure. So, here it is…What artifact types (and in most cases the events on the artifacts) must be enabled to be available in the audit. Note that the more you enable, the larger your audit trail information will grow!
One ring to rule them all, so here it is, the artifact that gives you inside in all the synchronized BAM data in one big dashboard from where you can filter done to the correct information. Now information now, but it will get information when we start again with BPM processes and the generated BAM data.
If you want to work with google services (and in this case the google maps API) you need a google API key. And instead of typing the key over in several location it’s better to save it on one location and reuse it from this location…It’s what it is…Nothing more and nothing less…We’ll if we make a post out of it in the future.
The information about your license can be found here. Also, the update of the license can be applied here. But make sure you still apply to your hostname settings for the VM as this information is connected to the license information. Also, nice to view the ‘Report Information’ that is normally send out to I guess OpenText.
The is the view endpoint from the ‘MDM admin config’ artifacts. In the admin config you define what needs to be saved in the MDM database and this is the viewer where you can define all kind of dashboard on the several datastores that are available for BAM…BAM?….Yes…Remember this block of information:
MDM is just all the persistent object data generated in the solution and synchronized to the BAM database…BAM is just the monitoring information of our process information. But not only processes…also MDM information (named as ‘MDM entities’).
When we start with BPM, we will also focus on the artifact again.
Here we are back to the start of our journey. This was the first artifact we used to create a new organization which is needed to start with all you workspaces and projects. Make sure to always make one person an administrator for your organization.
First, you need to have your UDDI service up and running and registered in the platform. When any of those services require any authentication, this is your place to be. Not for now, but we’ll see it again once we start with services that require authentication.
Other artifact are already described in the ‘Developer’ and ‘Administrator’ role section.
And that concludes our long list of artifacts that are available on the AppWorks platform…but…before we finalize things take a last look at this ‘insiders’ note!
OpenText is not investing very heavily into the items around BAM. They can still be used, but it might be a better solution to make the step to ‘Process Intelligence’ together with iHub. This option makes it possible to not only monitor BPM, but also the ‘Lifecycle models’ together with the ‘Case models’ (a special type of lifecycle)
I give it a fine ‘DONE’ as the list became longer as I expected. But lots of information to start and learn from so my backlog is getting bigger and bigger…Which is off-course a good thing. Have a good one for today and I see you in the next post.
Don’t forget to subscribe to get updates on the activities happening on this site.